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Introduction 


"It's  the  exception  that  proves  the  rule." 

- Oid  chestnut 

The  goal  of  much  of  the  current  research  in  the  field  of  "structured 
programming"  is  to  develop  a methodology  that  materially  aids  in  the  construction  of 
clearly  understandable  yet  rigorously  vc  ifiablt*  programs  No  single  methodology 
has  achieved  pre-eminence,  but  some  ommon  threads  run  through  all  the  serious 
contenders,  lo  achieve  Clarity  of  express  n most  methodologies  postulate  a .mall 
number  of  easily-described  primitive  programarng  constructs.  (By  "easily- 
described"  we  mean  a construct  has  both  a straight-forward  intuitive 
characterization  and  a precise  axiomatic  definition  of  Its  semantics.)  These 
constructs  then  become  the  building  blocks  for  programs  that  exhibit  an  orderly 
arrangement  of  data  aru  disciplined  transfers  of  control. 

lo  date,  progress  in  this  area  has  mostly  been  exhibited  in  successful 
"laboratory  experiments".  With  a few  notable  • • t >ns  (e.g.  the  New  vork  Tam  s 

system  [Baker  /’?]),  the  demonstrations  of  the  utility  of  such  methodologies 
have  been  small-scale  examples  or  toy  systems.  We  contend  that  this  is  not  an 
accident;  we  claim  that,  to  date,  pr  gramming  methodologies  have  largely  failed  to 
address  a crucial  nspe  { of  practical  program  cor  .trur.bon  exception  handling.  The 
absence  of  methodologically  sound  language  facilities  for  expressing  behavior  under 
exceptional  circumstances  has  limited  our  ability  to  describe  complex  processing 
clearly  and  precisely  The  goal  of  this  thesis  is  to  supply  those  missing  facilities  In 
the  words  of  the  ancient  cliche  that  introduces  this  chapter,  we  intend  to  test 
(prove)  the  "rule"  of  proposed  programming  methodologies  to  discover  if  they  can 
be  extended  to  handle  both  normal  and  exceptional  cases  with  equal  ease  and 
clarity  of  expression. 
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1.1  What  is  an  Exception? 

We  cannot  give  a terse  definition  of  'exception'  that  would  adequately  serve 
the  intent  of  this  thesis.  To  claim  an  exception  is  a raiely  occurring  event  merely 
begs  and  distorts  the  question.  Frequency  only  has  meaning  in  a relative  sense, 
and  the  same  event  may  occur  relatively  often  in  ore  context  and  relatively  rarely 
in  another  As  a simple  example,  consider  the  operation  that  looks  up  a symbol  in  a 
compiler's  symbol  table.  It  has  two  obvious  possible  outcomes:  'symbol  present'  and 
'symbol  absent'.  Although  we  tend  to  view  the  former  as  'normal'  and  the  latter  as 
'exceptional',  this  is  purely  a psychological  prejudice  If  the  'lookup'  operation  is 
used  to  determine  the  interpretation  of  a symbol  in  a program  body  (as  opposed  to 
the  declarations),  then  'symbol  absent'  probably  corresponds  to  'undeclared 
identifier'  - an  exceptional  condition  in  most  cases.  If,  however,  the  'lookup' 
operation  is  used  during  declaration  processing,  then  'symbol  absent'  is  probably 
the  'normal'  case  and  'symbol  present'  (i.e.  'duplicate  definition')  the  exception. 
What  constitutes  an  exception  evidently  depends  on  the  context  in  which  an  event 
occurs. 

Context  is  not  the  only  factor  - the  language/system  in  which  computations 
are  expressed  markedly  influences  the  designation  of  exceptions.  Some 
structures,  notably  production  systems  [Rychener  F6]  and  Dijkstra's  guarded 
commands  [Dijkstra  76],  encourage  the  programmer  to  define  the  normal  case 
and  the  exceptions  with  the  same  syntax.  Such  'event-driven'  systems  obviously 
have  no  need  for  special  language  constructs  to  express  exception  handling 
behavior.  Yet  they  are  not  ideal  in  some  respects.  Because  all  events  are 
represented  similarly,  a reader  of  a program  may  experience  difficulty  in  separa'  ng 
the  primary  computation  from  the  special  cases.  Clarity  therefore  may  fie 
sacrificed.  Fven  if  It  is  not,  production  systems  rnay  not  provide  the  appropriate 
structure  for  many  practical  tasks,  which  often  requite  the  more  conventional 
facilities  of  a procedural  language.  Procedural  languages,  list'  m illy,  have 
provided  few  constructs  for  exception  handling  (see  chapter  ?)  and  will 
therefore  be  the  primary  vehicle  for  the  mechanism  proposed  in  this  thesis 
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Exceptions  are  sometimes  called  'errors',  but  we  reject  the  connotations  ot 
that  term  and  strenuously  avoid  its  use.  An  'error'  is  usually  an  event  whose 
occurrence,  though  not  unexpected,  is  not  essential  to  the  correct  completion  ot 
the  primary  computation,  and  may  be  detrimental.  We  prof  ''  to  take  a broader  v;ew 
that  includes  such  ’errors’  as  a proper  subset  of  exceptions  allowing  (r*  rtiv  • . I 
infrequent  events  to  qualify  ns  exceptions  as  well.1  In  doing  so  wo  delihe-.itclv 
allow  exceptions  to  spill  over  into  the  area  of  commun-cation  fn  ilitii  s f or  sample, 
the  indication  that  an  I/O  operation  has  completed  may  hr  v ■ vod  as  either  ,n 
exception  (relatively  infrequent  event)  or  a ommnnic-iti  » ugna'  depending  i pon 
the  usage  context.  We  consider  the  existence  of  this  fu.  .*y  boundary  to  suuo  <-t 
robustness,  not  sloppiness,  in  an  exception  handling  me  harusm  A sharf  line  of 
demarcation  would  probably  limit  the  flexibility  of  programs  operating  near  it. 

We  are  led,  therefore,  to  ask  what  distinguishes  exception  handling  from  m re 
general  communication  between  program  units.  Again,  hr  a use  of  the  jverlap,  wt 
cannot  make  a sharp  separation.  Generally,  the  use  of  an  exception  handling 
mechanism  is  preferable  when  a programmer  wishes  to  'play  down'  the  si  ecial  t ase 
processing  in  a particular  c ontext.  An  exception  mecl  am.sm  should  tie  able  to  limit 
the  visibility  of  such  processing,  suppressing  detail  where  desirable,  so  that  the 
primary  computation  can  be  she  ed  It  may  also  distribute  the  costs  rather 
differently  than  a general  communication  facility  does.  Thus  the  choice  of  an 
exception  or  communication  mechanism  may  he  a . sitter  of  the  programmer's  taste, 
assuming,  of  course  that  both  provide  adequate  function  at  ac  i ■ ptat  lo  cost 


1 .2  Motivation  and  Background 

Why  worry  about  exception  processing?  Anyone  who  has  ever  built  a large 
software  system  or  tried  to  write  a 'robust'  program  nan  appreciate  the  problem.  As 
programs  grow  in  si/e,  special  cases  and  unusual  circumstances  crop  up  with 
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startling  rapidity.  Even  in  moderate-sized  programs  that  perform  seemingly  simple 
tasks,  exceptional  conditions  abound.  Consider  a tape-to-tape  copy  program.  Any 
reasonable  programmer  will  handle  an  end-ot-file  condition,  since  it  probably 
indicates  completion  of  the  copying  operation.  But  wiiat  about  tape  errors?  End- 
of-tape?  Hung  device?  Record  larger  than  expected?  We  could  enumerate  other 
possible  exceptions,  but  the  point  is  clear.  Exceptions  exist  even  in  the  simplest 
problem,  and  the  complexity  they  induce  in  large  programs  can  be  mind-boggling. 
We  contend  that  no  mechanism  has  yet  been  implemented  or  proposed  that  can 
control  this  complexity.  A look  at  the  (disorganization  of  existing  large  systems 
should  easily  convince  us  that  such  control  is  essential  if  we  ever  hope  to  make 
these  systems  robust,  reliable,  and  understandable.  This  thesis  provides  an 
exception  mechanism  egual  to  that  task. 

Although  it  is  obvious  that  any  exceptional  condition  that  arises  must  be 
handled  if  our  programs  are  to  be  robust,  we  might  wonder  whether  we  need  a 
single,  general  mechanism  to  do  so.  Why  not  simply  test  explicitly  for  an  exception 
at  all  possible  points  in  the  program  where  it  can  occur?  If  this  is  prohibitively 
expensive  or  inconvenient,  why  not  test  only  at  a selected  subset  of  these  points? 
No  special  mechanism  is  required  here,  and  the  code  to  detect  these  exceptions  is 
explicit  and  under  the  programmer's  control. 

The  objections  to  this  ad  hoc  approach  should  be  clear.  For  some  classes  of 
exceptions  (e  g.  I/O  completions),  the  condition  may  occur  virtually  anywhere  in  the 
program.  Obviously,  it  is  impractical  to  include  an  explicit  test  "at  all  possible 
points"  where  such  exceptions  can  arise.  Polling  at  "selected"  points  may  be 
feasible  in  principle,  but  in  practice  destroys  the  structural  coherence  of  the  source 
program  Because  of  timing  considerations,  it  often  becomes  necessary  (with  e 
polling  scheme)  to  introduce  tests  for  exceptions  into  pieces  of  the  program  that 
have  nothing  to  do  with  the  condition  being  tested.  It  is  then  Impossible  to  rend  and 
understand  such  a program  segment  without  understanding  the  entire  structure  of 
which  it  is  a (perhaps  very  small  and  localized)  part.  Explicit  polling  may  suffice  in 
very  limited  applications  hut  is  clearly  inadequate  for  general  use.  A technique 
must  be  found  that  preserves  structural  clarity. 

Once  we  begin  to  search  for  a more  suitable  exception  handling  technique,  we 
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find  it  useful  to  subdivide  the  problem.  We  may  view  the  process  of  handling  an 
exception  as  consisting  of  three  phases:  detection  of  the  condition,  transmission  o* 
the  notification  of  its  existence,  and  diagnosis  and  recovery  from  the  (implied) 
problem.  Detection,  diagnosis,  and  recovery  are  exception-specific,  although 
common  techniques  may  be  applied  for  many  exceptions  Indeed,  there  exist 
methodologies  that  seek  to  address  and  codify  these  techniques  [Pollack  77] 
This  topic  is  beyond  the  scope  of  this  thesis;  we  will  concentrate  our  attention  on 
the  transmission  of  exception  notifications.  It  will  be  our  goal  to  provide  a general 
mechanism  to  pass  information  about  an  exception  between  the  point  of  its 
detection  and  the  points  at  which  it  may  be  processed  intelligently. 

The  historical  motivation  for  this  work  should  be  briefly  mentioned.  For  many 
years  I have  been  annoyed  with  the  incompleteness  of  the  specifications  of  various 
(software  and  hardware)  facilities  I have  attempted  to  use.  The  problems  arise  not 
in  understanding  the  'normal  case1  behavior  of  a facility  - that  is  (nearly)  always- 
defined  clearly.  Discovering  the  behavior  under  unusual  circumstances  is  another 
matter,  since  the  author  of  the  specifications  has  rarely  bothered  to  ask  himself: 
"What  if  ...".  Consequently,  the  specifications,  and  often  the  facility  as  well,  do  not 
address  exceptional  conditions.  I became  painfully  aware  of  the  difficulty  of 
defining  exceptional  behavior  in  a large  system  during  the  design  and  construction 
of  the  Hydra  kernel  [Wulf  74].  The  implementation  language  available  (BLISS- 
11  [DEC  74])  did  not  provide  sufficiently  powerful  tools  for  exception  handling, 
yet  a significant  fraction  of  the  operating  system  code  was  devoted  to  detecting, 
transmitting,  and  processing  exceptions.  This  experience  convinced  me  that  a 
general  mechanism  was  needed  that  could  serve  as  the  basis  for  the  precise 
specification  of  exceptions.  But  what  properties  should  it  have?  In  seeking  to 
answer  that  question,  I embarked  upon  the  work  reported  in  this  thesis. 

1 .3  Goals  and  Scope  of  the  Thesis 

For  reasons  suggested  above,  we  will  concentrate  on  exception  handling 
facilities  in  a generally  procedural  language,  The  precise  syntax  and  semantics  of 
such  a mechanism  will  necessarily  be  influenced  by  the  language  and  system  in 
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which  it  is  embedded.  Nevertheless,  we  can  identify  desirable  properties  that  a 
general  mechanism  should  exhibit  before  it  can  be  considered  'eligible'  for 
implementation.  These  properties  will  serve  os  goals  to  be  attained  by  our 
proposed  mechanism.  We  briefly  present  these  goals  here;  they  will  be  explored  in 
greater  depth  in  chapter  3. 


1.3.1  Verifiability 

Any  proposal  for  a new  language  mechanism  should  be  closely  scrutinized  to 
determine  the  effect  of  the  proposed  facility  on  program  structure  Existing 
mechanisms  frequently  exhibit  glaring  inadequacies  in  this  respect,  and,  as  a result, 
induce  complex  and  confusing  program  structures.  It  is  difficult  to  require  clarity 
and  measure  it  quantitatively,  which  perhaps  accounts  for  much  of  the  current 
debate  on  language  constructs  to  support  structured  programming.  We  maintain 
that  clarity  in  an  exceptional  condition  mechanism  is  of  the  utmost  importance,  for 
the  following  reason.  If  we  consider  'robust'  programs  (i.e  those  that  handle  most 
of  the  exceptional  conditions  that  can  occur  in  their  execution  environment),  we 
find  that  a large  fraction,  if  not  an  actual  majority,  of  their  code  is  devoted  to 
exceptional  condition  handling  ? Recalling  the  oft-quoted  observation  that  a 
program  spends  90*/.  of  its  execution  time  in  107.  of  its  code,  we  would  expect  to 
find  exceptional  condition  handling  code  concentrated  in  the  infrequently  executed 
907.  of  the  program  tfjxt.  Both  the  high  proportion  of  exceptional  condition  handling 
code  and  the  infrequency  of  execution  argue  strongly  for  language  mechanisms  that 
strive  for  clarity.  But  since  clarity  is  impossible  to  guarantee  in  practice,  we 
demand  instead  verifiability,  believing  that  constructs  that  are  easily  verified  are 
generally  easily  understood. 

We  will  require  that  a general  exceptional  condition  mechanism  be  amenable 
to  formal  verification  at  a level  consistent  with  the  other  constructs  in  the 
language.  This  implies  that  the  essential  (i  e.  language  independent)  semantics  of 
the  mechanism  must  observe  program  structuring  principles  that  have  been  shown 
to  facilitate  verification,  e.g.  locality  of  refuionce  to  data  structures  and  disciplined 
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transfer  of  control.  Of  course,  the  adaptation  of  the  mechanism  for  a specific 
implementation  must  also  respect  these  principles  Verifiability  will  be  an  essentia! 
property  of  a well-structured  exception  handling  mechanism. 


1.3.2  Uniformity 

A fundamental  problem  with  existing  mechanisms  is  that  they  provide  an 
acceptable  means  of  handling  only  limited  classes  of  exceptions.  When  a largo 
software  system  is  constrm  ted  using  several  such  mechanisms,  the  interfar-  s 
between  different  parts  become  awkward,  inc: .insistent,  difficult  to  understand,  and 
consequently  error-prone  A general  mechnr  ism  permits  a pleasing  uniformity  of 
expression  at  all  levels  of  the  system  and  for  all  excel  tions,  facilitating 
understanding  and,  incidentally,  simplifying  verification  conditions.  We  want  o n 
exceptional  condition  handling  mechanism  to  b<  applicable  at  all  levels  in  a software 
system,  from  user  program  to  operating  system/hardware  interface  (This  may 
force  a substantial  change  in  the  way  we  view  peripheral  devices,  but  if  it  permits 
a uniform  approach,  it  is  worthwhile.)  We  may  he  c ompelled,  by  the  limitations  of 
physical  implementation,  to  require  only  that  hardware  provide  a subset  of  the 
general  mechanism's  facilities;  however,  that  subset  in  itself  will  be  consistent  with 
the  other  goals  of  the  mechanism,  namely  verifiability  and  adequacy. 

It  is  important  to  note  that  uniformity  in  application  of  the  mechanism  does  not 
constrain  us  to  live  with  a single  implementation  at  all  levels  and  for  all  conditions. 
Indeed,  the  implementation  of  (the  subset  of)  the  general  mechanism  in  hardware 
will  obviously  bo  different  from  the  implementation  in  software.  The  same  holds  true 
for  operating  system  and  user;  the  implementations  of  a single  conceptual  facility 
may,  and  probably  will,  differ.  It  may  even  he  possible  that  several  distinct 
implementations  will  exist  within  a single  (large)  piece  of  the  system  (this  is  true, 
for  example,  in  the  kernel  of  Hydra  [Wutf  74]).  We  will  require  uniformity  only 
in  the  functional  specification  of  the  mechanism. 


^ Wf  might  extend  (hi*  argument  and  propose  a single,  unified  syntax  and  semantics  for  general  control  flow. 
Indeed,  this  is  done  in  production  systems  [Ryrhene'  Our  reasons  for  not  doing  so  ai e discussed  in  section 
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1.3.3  Adequacy 

While  we  may  define  a mechanism  that  is  uniform  at  all  system  levels  and  that 
lends  itself  easily  to  formal  verification,  we  do  not  thereby  insure  that  it  is  useful 
To  he  worth  implementing,  the  mechanism  must  he  capable  of  solving  a variety  of 
'real  world'  problems  naturally.  This  last  word,  "naturally",  is  the  fly  in  the  ointment, 
since  it  implies  an  aesthetic  judgment  of  a particular  problem  formulation.  We  do  not 
hope  to  prove  that  the  proposed  mechanism  is  'complete',  (that  is,  that  it  will  -olve 
all  exceptional  condition  handling  problems.)  Even  if  we  could  do  so,  we  could  not 
prove  that  it  would  do  so  "naturally".  Accordingly  we  settle  for  a notion  of 
'adequacy',  far  weaker  than  completeness,  which  merely  shows  that  the  mechanism 
is  indeed  good  for  something.  We  will  demonstrate  'adequacy'  inductively  by 
example  rather  than  deductively  by  proof.  However,  as  a specific  condition  on 
adequacy,  we  will  demand  that  the  mechanism  accommodate  parallel  as  well  as 
sequential  programming,  for  to  restrict  it  to  one  or  the  other  is  to  exclude  a major 
source  of  'real  world'  exceptional  condition  handling  problems. 


1.3.4  Practicality 


It  is  not  sufficient  merely  to  define  a mechanism  whose  functionality  makes  it 
wortli  implementing  We  must  also  be  able  to  deliver  that  functionality  with 
reasonable  efficiency.  No  programmer  will  take  advantage  of  the  mechanism  if  the 
implementation  makes  It  too  costly  to  use.  We  must  supply  the  Intended  function  at 
a cost  that  is  attractive  to  the  programmer,  for  otherwise  he  may  employ  other 
language  constructs  to  accomplish  the  exception  handling  function  . and  sacrifice 
clarity  in  the  process.  While  the  programmer  need  not,  in  general,  be  acquainted 
with  the  Implementation  of  the  exception  mechanism,  he  is  entitled  to  know  that  It 
supplies  the  advertised  function  at  a cost  that  Is  competitive  with  alternate 
language  constructs. 
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1.3.5  Summary  of  Properties 

These  properties,  then,  characterize  the  fundamental  requirements  for  a 
general  exceptional  condition  handling  mechanism.  We  asseit  that  a mechanism 
exhibiting  these  properties  represents  an  advance  in  the  state  of  the  art,  since  no 
existing  mechanism  meets  these  requirements.  (The  supporting  Evidence  is  Ir, 
chapter  2)  We  are  requiring  that  our  new  mechanism  be  able  to  solve  a 
collection  of  practic  ai  problems  that  heretofore  have  been  handled  only  by  a variety' 
of  ad  hoc  techniques  Furthermore,  we  require  that  it  do  so  not  by  a jumble  of 
loosely-integrated  facilities,  but  by  a single,  uniform  mechanism  that  can  be  formally 
proved  to  behave  in  precisely  specified  ways  finally,  it  must  be  implement ab'e 
with  low  enough  cost  to  be  of  practical  utility. 


7 .4  Synopsis  of  the  Thesis 

We  cover  the  topic  of  exception  processing  in  four  stages,  which  correspond 
to  the  four  major  parts  of  the  thesis.  Part  I introduces  the  topic  in  two  chapters. 
This  chapter  has  established  goals  for  the  remainder  of  the  work.  Chapter  2 
surveys  previous  approaches  to  exception  processing  and  evaluates  them  in  terms 
of  the  goals  of  the  preceding  section.  With  firs  background  established,  part  II 
proceeds  to  a presentation  of  a new  mechanism.  First,  chapter  3 elaborates 
the  goals  and  explores  their  implications  on  the  structure  of  the  mechanism,  then 
chapter  4 presents  the  details  of  that  mechanism,  concentrating  on  an 
operational  specification  in  language-independent  terms. 

Part  Ml  demonstrates  that  the  mechanism  of  part  II  meets  the  goals  laid  down 
in  part  I.  Chapters  5,  6,  7,  and  8 each  address  one  goal  in 
detail,  relating  the  specifics  of  the  proposed  mechanism  to  the  concerns  embodied 
in  the  general  statements  above  Finally,  part  IV  summarizes  the  content  of  this 
work  and  considers  the  remaining  unsolved  problems  and  possible  future  solutions. 


2 

Survey  of  Existing  Exception  Handling  Mechanisms 

My  object  all  sublime 
I shall  achieve  in  time  - 
To  let  the  punishment  (it  the  crime  - 
The  puni  shment  tit  the  crime. 

- W.  S.  Gilbert,  The  Mikado 

To  acquire  some  perspective  on  the  state-of-the-art  in  exceptional  coml  tion 
handling,  we  will  examine  programming  language  and  system  mechanisms  that  have 
been  used  or  proposed  for  this  purpose.  Naturally,  our  survey  does  not  include 
every  language  or  construct  that  has  attempted  to  address  the  problem,  but  it  docs 
cover  the  techm  gues  that  have  been  applied  We  include  in  our  list  a few 
mechanisms  that  have  been  proposed  but  not  implemented 

2.1  Some  E Kcoption  Handling  Issues 

Before  embarking  on  a survey  of  existing  exception  handling  techniques,  we 
briefly  enumerate  some  issues  that  will  arise  frequently  in  subsequent  discussions. 
Wo  do  not  atft  mpt  here  to  explore  those  issues  in  depth;  we  merely  list  thorn  as 
questions  to  he  at  tressed  both  by  the  existing  mechanisms  described  in  this 
chapter  and  the  propc  'd  mechanism  presented  in  chapter  4 


Spec  if  ir  ation  - How  are  exceptional  conditions  defined?  Are 
their  semantics  formally  specified?  What  is  the  space  of 
situations  to  which  they  may  apply? 

hbstrm  tion  and  Program  Structure  - How  does  the  exception 
nu  • Irani:. m aid  m nbstrac  tion?  Docs  it  aid  in  tire  decomposition  of 
programs  along  abstraction  boundaries?  Is  it  possible  to  process 
an  exception  without  knowing  tire  representations  employed  by 
the  program  that  detects  it? 
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* Sharing  - Does  the  mechanism  recognise  shared  abstractions?  If 
an  abstraction  is  shared  among  several  contexts,  can  exception 
processing  related  to  that  abstraction  be  shared  as  well? 

* Programming  Flexibility  - To  what  extent  does  the  exception 
mechanism  influence  non-exceptional  processing?  Does  it 
restrict  the  set  of  permissible  control  and  data  structures? 

* Language  - What  restrictions  and  assumptions  does  the  exception 
mechanism  impose  upon  the  language  in  which  it  is  embedded? 

Are  its  requirements  relatively  general  or  highly  language- 
specific?  How  closely  is  it  bound  to  global  language  properties, 
e.g.  sequential  processing? 

* Verification  - How  does  the  mechanism  affect  the  verifiability  of 
its  embedding  language?  In  what  ways  does  the  desire  for 
verification  constrain  the  semantics  of  the  exception  mechanism7 

* Cost  - What  is  the  cost  of  using  the  mechanism,  and  how  is  that 
cost  distributed?  Is  the  mechanism  competitive  with  potentially 
attractive  alternate  constructs  in  the  embedding  language? 

This  list  Is  by  no  means  exhaustive,  hut  it  samples  the  most  important  issues. 
The  questions  are  substantial  ones,  and  are  often  directly  or  subtly  inter-related. 
In  the  survey  that  follows,  we  will  not  attempt  to  examine  each  issue  in  the  light  of 
encli  mechanism;  rather,  we  will  try  only  to  assess  the  prominent  strengths  arid 
weaknesses  of  each  mechanism  in  terms  of  this  list 


2.2  Sequential  Mechani sms 

By  far  the  majority  of  exception  handling  mechanisms  address  only  the 
problem  of  sequential  programming,  for  obv  ous  historical  reasons.  We  will  consider 
the  development  of  sequential  mechanisms  m mu  pily  chronological  order. 
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2.2.1  Unusual  Return  Value 

Perhaps  the  most  primitive  form  of  exceptional  condition  handling  mechanism  is 
the  'unusual  return  value'  from  a subroutine  invocation,  indicating  that  some 
abnormal  event  has  occurred.  This  technique  is  ns  old  as  the  subroutine  concept 
itself,  and  is  probably  best  viewed  as  a degenerate  form  of  exceptional  condition 
mechanism.  Its  obvious  deficiencies  include  cost  (the  condition  must  be  explicitly 
checked  and  'passed  up'  at  all  program  levels),  poor  abstraction  characteristics  (it 
tends  to  lead  to  programming  puns  that  are  based  on  internal  data  structure 
representations  within  the  computer),  and  imprecise  specification  While?  the 
unusual  return  value  has  some  utility  in  very  localised  contexts,  in  general  it  is 
heavily  over-used  and  is  practically  a cliche  among  exception  handling  constructs. 


2.2.2  Forced  Branch 

The  simplest  form  of  exception  handling  mechanism  that  actually  involves  a 
non-standard  control  structure  is  the  forced  branch.  In  assembly  language  this 
mechanism  frequently  appears  as  a 'skip  return'  from  a subroutine,  i.e.  the 
instruction  immediately  following  the  subroutine  call  is  or  is  not  skipped  to  indicate 
the  presence  or  absence  of  an  exceptional  condition.  In  FORTRAN  IV  and  ALGOL  60 
this  mechanism  is  generalized  to  permit  several  lalrels  to  be  passed  as  parameters 
to  a subroutine,  such  labels  being  treated  as  possible  alternate  return  points.  The 
central  notion  is  that  the  callee  detects  an  exceptional  condition  and  performs 
some  fixod  action  (e  g.  add  one  to  the  return  address  and  exit,  or  branch  to  the 
location  specified  by  the  third  parameter),  which  is  used  by  the  caller  to  initiate  a 
condition  handler.  Such  mechanisms  generally  impose  little  or  no  overhead  in  the 
'normal  return'  case,  and  thus  eliminate  the  cost  of  explicit  checking  inherent  in  the 
unusual  return  value.  However,  they  raise  serious  program  structuring  issues. 
I nilure  by  a caller  to  provide  a legitimate  handler  for  every  condition  tire  callee  can 
signal  may  lend  to  unpredictable  or  catastrophic  results  at  run-time.  (In  some 
FOR  IRAN  IV  Implementations,  for  example,  omission  of  a second  label  paiamoter  to  a 
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subroutine  that  expects  three  does  not  result  in  a compile-time  error,  and,  at  run- 
time, may  lead  to  the  handler  for  the  thiid  alternate  return  being  invoked  wtien  the 
second  was  intended  and  without  any  error  message.)  Also,  the  use  of  simple 
labels  to  specify  exceptional  condition  handlers  (instead,  for  example,  of  seb  outlne 
names)  encourages  programmers  to  merge  where  possibje  the  code  tor  such 
handlers  with  the  main-line  program  and  other  handlers,  in  a mistaken  attempt  at 
'efficiency'.  It  then  becomes  extremely  difficult  to  determine  how  many  cell  sites 
reference  a particular  piece  of  handier  code  and  what  the  possible  program  states 
can  be  on  entry  to  that  handler.  These  undisciplined  transfers  of  control  complicate 
the  task  of  verifying  the  correctness  of  a subroutine  in  much  the  some  way  as  the 
general  goto  does. 


2.2.3  PJon-local  GoTo 

A similar  (though  less  desirable)  construct,  which  appears  in  ALGOL  60  arui 
some  other  block-structured  languages  is  the  non-local  goto  (i.e  a goto  that 
specifies  a destination  outside  the  procedure  in  which  it  appear  ).  this  device  l as 
little  to  recommend  it  on  program  structuring  grounds,  for  it  gives  the  caller  very 
little  control  over  the  choice  of  handler  and  further  blurs  the  distinction  (in  the 
calling  program)  between  main-line  and  exceptional  condition  handling  code  hr 
addition,  although  tire  non-local  goto  permits  the  exception  notification  to  pass 
outside  the  detecting  procedure  (a  desirable  property),  it  forces  the  handler  ('  e 
the  target  label)  to  appear  in  a lexically  enclosing  block.  Such  a structure  is  rarely 
appropriate;  the  calling  block  (which  may  not  he  lexically  enclosing)  can  normally 
supply  a more  meaningful  handler.  Furthermore,  the  non-local  goto  may  abort  the 
calling  procedure  without  giving  it  an  opportunity  to  "clean-up"  its  data  structures, 
this  undisciplined  transfer  of  control  exhibited  by  the  general  goto  is  a sourc  of 
many  verification  difficulties  in  languages  that  possess  It. 
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2.2.4  Procedure  Variables 

Languages  that  permit  variables  to  refer  to  procedures  contain  the  basis  of  a 
primitive  exception  mechanism.  Algol-68  [van  Wijngaarden  75]  provides  the 
most  completely  developed  example  of  this  approach  Iri  Algol-68,  input/output 
occurs  on  'files',  which  are  represented  by  a data  structure  that,  among  other 
quantities,  contains  a number  of  procedure  variables.^  Fach  such  variable  is 
associated  with  a particular  exceptional  condition,  e g.  logical  end-of-file.  Who-  an 
exception  arises,  the  appropriate  procedure  variable  is  used  to  locate  a procedure 
that  is  to  be  invoked  in  order  to  process  the*  condition.  Depending  on  the  (boolean) 
value  returned  by  the  procedure,  the  file  manipui  it  ion  procedure  that  detected  the 
exception  either  completes  or  "takes  some  sons'hle  action". 

I his  association  of  procedures  with  objects  has  been  called  "object-oriented 
exception  handling"  [Goodenouyh  75]  and  is  not  un  one  to  Alqol-68  (see,  e.q 
[Ross  67]).  There  are  a few  twists,  however,  to  the  Algol-68  approach  that 
aie  worth  noting.  Since  a file  in  Aiqol-68  is  a 'structured  value'  (a  'record'  in  the 
sense  of  Alyol-W  [Wirth  66]  and  a number  of  other  languages),  one  might 
expect  that  a user  of  a file  could  alter  the  "exception  handling  procedures"  by 
storing  into  the  appropriate  fields  of  the  'file'  data  structure.  However  Algol-68 
does  not  permit  direct  user  access  to  a f le1.  and  provides  instead  'event  routines' 
that  perform  store1  operations  into  the  file's  procedure  variables.  Thus  instead  of 
writing 

I og i ca I file  end  o 1 my  da  la  file  : - eo  f hand  I pr 

where  'oof  handler'  is  a procedure  name  and  'logical  file  end'  is  the  relevant  field  of 
’my  data  file',  one  must  write 

on  I og i al  fi Ip  end (my  data  file,  ‘-of  handler) 

^ Algol  * fi&  docs  not  ijs*»  the  !f*rm  'pro^dgre  s.VMblc';  rath°',  t*  o ■ hon  is  a ' r ° ' 'd  r.isc  c*  th*»  more  Q^'T'a' 
concept  of  'mode'.  in  this  d'sruss»on  we  vv  1 • t tit**  m e ' '.^-ntiona  , th'iqh  l**<;s  preese,  names  for  tt»e 

[>r>'  sih'ly  unf.imtliar  terrmroh-gy  of  Ale  1 r,ft 
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Here,  the  event  routine  'on  logical  file  end'  performs  the  desirt  d association.  We 
prefer  the  latter  form  as  well,  but  for  structuring  rather  than  efficiency  reasons.  By 
forcing  the  use  of  event  routines,  Algol-68  is,  in  effect,  preventing  direct  external 
manipulation  of  the  'file'  data  structure.  The  representation  of  a 'file'  can  then  be 

O 

freely  changed  without  necessitating  changes  in  the  programs  that  use  it. 

Evidently,  procedure  variables  are  a powerful  language  facility  that  can  be 
pressed  into  service  as  an  exception  handling  mechanism  However,  as  formulated 
in  Algol-68,  they  are  not  ideal  for  this  purpose.  First,  the  Algol-68  scope  rules 
require  that  a procedure’s  scope  be  no  smaller  than  the  scope  of  the  procedure 
variable  to  which  it  is  assigned.  In  terms  of  our  example  above,  the  scope  of  'oof 
handler'  must  encompass  the  scope  of  'my  data  file'.  While  this  stringent 
requirement  helps  prevent  dangling  pointers,  it  makes  practical  exception 
processing  rattier  inconvenient,  since  it  lumts  our  ability  to  construct  proreduies 
that  will  handle  the  exception  only  in  a very  localized  context.  Second,  only  a 
single  procedure  is  ever  invoked  in  response  to  an  exception,  though  there  may  be 
many  contexts  in  which  recovery  actions  may  (should)  be  attempted.3  Although  we 
can  build  composite  structures  that  hold  more  than  one  procedure  variable,  we  do 
not  have,  in  Algol-68,  adequate  information  to  maintain  this  structure  without  an 
undue  amount  of  user  assistance.  In  seeking  to  acquire  tnat  information  (e  g the 
contexts  in  which  the  user  is  executing  when  tiie  exception  is  detected),  we  are 
again  stymied  by  the  rigid  scope  rules.  Third,  procedure  variables  make  it  difficult 
to  discover  exactly  what  action  will  be  taken  when  a particular  exception  occurs 
The  body  of  exception  processing  code  may  be  (lexically;  far  removed  from  the 
invocation  of  a function  that  triggers  it  Clarity  is  essential  (see  section  1.3)  and 
should  tie  encouraged  in  an  exception  mechanism. 

We  should  not  overlook  the  desirable  properties  of  t ho  Algol-68  approach. 
F xcoptlon  handlers  are  procedures  and  thus  return  to  ‘heir  invokers,  permitting  the 


‘ It  is  noteworthy  that  the  final  rcpoit  on  Algol  R8  [va  Wijmiaarden  /f>]  inn  limes  event  ' lines  purely  to 
permit  efficient  implementation  of  transput.  (The  original  report  [ s an  Wijnuaarden  69)  had  no  Mjch  notion; 
exception  handling  procedures  were  altered  by  direst  a:  gnmenl  ) for  structures  defined  by  an  Algol -ft 8 user,  the 
component  fields  cannqj  he  made  inaccessible  and  thus  the  ■■■  " ot  rout,  es  lo  a'ter  the  fields  cannot  be  enforced 
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We  will  discuss  this  issue  in  detail  in  chapter  0 
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detector  of  the  condition  to  respond  to  the  recovery  action  taken  ^ Handlers,  being 
general  procedures,  are  parameterized,  and  communication  through  global  variables 
is  therefore  unnecessary  (in  contrast  with  PL /I  ON  conditions,  below),  finally, 
handlers  are  associated  with  the  object  rather  than  the  operation  - an  important 
step  in  the  direction  of  proper  abstraction  The  mechanism  of  chapter  d will 
build  on  all  of  these  properties. 


2 2.5  PL/I  ON  Conditions 

We  now  come  to  mechanisms  that  provide  a means  of  passing  over  dynamic 
program  levels.  The  PL/I  OH  condition  r.  h.i  sm  (IBM  , .)]  was  per  aps  the 
first  attempt  to  provide  a true  exceptional  < ondibon  mechanism  in  a general  purpose 
high-level  language  ( outfit  ions'  are  p « pluutly  dr-  dared  ( actually,  thev  are  railed 
'events'),  and  triggered  by  a spe-  lal  st.it  ment  H,,  Hers  are  also  explicitly 
spec  died  and  asset  sited  with  purtn  ular  c cu,  lit  ms  A number  of  built-in  ' onditions 
( eg.  arithmetic  overflow,  end- of-file,  couvei  s-on  error)  are  signalled  by  the 
implementation,  but  may  t e handled  by  user  appla  d handlers  in  much  the  same 
way  us  programmed  conditions.  When  a condition  is  raised,  the  most  recently 
encountered  handler  in  the  dynamic  nesting  of  program  blocks  (usually)  re  ceives 
the  notification. 

Although  the  basic,  notion  1 eliind  ON  c nnditims  is  sound  it  does  not  mr  sh  well 
with  other  language  facilities  and  seems  to  have  been  conceived  largely  ns  n 
means  to  allow  programs  to  trap  a collection  of  system-defined  run-time  errors. 
While  it  attempts  to  accommodate  programmer-defined  condd-ons  and  even  parallel 
processing  (within  an  inherently  hierarchical  prora  ss  structure),  the  foundations  are 
weak  and  the  mechanism  remains  awkward  for  all  but  the  original  specialized 
conditions.  Specifically,  ON  conditions  suffer  from  reliance  upon  the  non-local  goto, 
absence  of  parameters  to  handlers,  and  n glaring  lack  of  uniformity  in  the  actions 
handlers  are  permitted  to  take.  We  have  already  considered  the  shortcomings  of 
the  non-local  goto.  The  absence  of  parameters  to  handlers  forces  them  to 
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communicate  with  the  signaller  through  shared  global  variables.  This  undisciplined 
access  to  data  engenders  many  of  the  same  verification  problems  that  the  general 
goto  does.  In  short,  the  weaknesses  of  the  ON  condition  mechanism  overshadow  its 
desirable  properties.  The  primary  contribution  of  this  first  attempt  at  high-level 
exception  handling  has  been  its  influence  on  subsequent  systems  (e  g.  BLISS 
[DEC  74],  MPS  [Lampson  74])  that  built  on  the  ON  condition  notion 

2.2.6  BLISS  Signal 

The  BLISS  'signal-enable'  construct  [DFC  74]  is  perhaps  the  simplest 
means  of  passing  over  dynamic  program  levels.^  Though  the  actual  mechanism  is 
slightly  more  general  than  described  here,  signal-enable  provides,  in  essence,  an 
explicit  means  of  defining  an  exceptional  condition  and  supplying  a handler  to 
respond  to  its  detection  The  handler  is  defined  by  an  enable  declaration,  which 
names  the  condition  and  specifies  a piece  of  program  text  to  be  executed  when 
the  condition  is  raised  via  a signal  statement  Handlers  are  associated  with  a 
lexical  block  (in  the  ALGOL  sense),  but  are  maintained  at  run-time  In  a LIFO  stack, 
so  that  the  most  recently  encountered  handler  (in  the  dynamic  block  nest)  for  □ 
signalled  condition  will  be  invoked.  A handler  itself  is  allowed  to  signal,  which 
permits  propagation  of  the  signal  to  a higher-level  block  Normal  (i.e  non-signalling) 
termination  of  a handler  terminates  the  block  in  which  the  handler  is  defined  There 
is  an  important  additional  form  of  enable  that  defines  a handler  capable  of 
processing  any  signalled  condition  The  signal-enable  mechanism  provides  no 
facilities  for  parameter  passing  (from  signaller  to  handler)  and  does  not  permit 
resumption  of  the  signaller  upon  completion  of  the  handler's  actions.  Furthermore, 
no  'passed  over'  intermediate  program  levels  are  informed  of  the  signalled 
condition's  occurrence;  these  blocks  must  include  appiopriate  enable  declarations 
for  exceptional  conditions  which  may  affect  their  execution.  In  spite  of  these 
weaknesses,  the  explicit  definition  of  handlers  and  special  syntax  for  signalling 
conditions  represent  important  advances  over  the  mechanisms  previously 
mentioned. 
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A functionally  *»rml ar  mechan.sm  is  described  in  [Fvon  76] 
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The  BLISS  mechanism,  while  adequate  for  many  applications,  has  some 
shortcomings.  The  inability  to  pass  parameters  from  signaller  to  handler  leads  to 
awkward  global  variable  usage,  which  In  turn  destrovs  the  potential  fnr  well- 
modularised  programs.  Also,  because  it  does  not  permit  a handler  to  return  to  the 
proyram  context  in  which  the  signal  occurred,  this  mechanism  is  only  useful  for 
'fatal'  errors;  that  is,  conditions  that  cannot  be  corrected  by  the  handler  without 
invalidating  the  interrupted  computation.  The;  R!  ISS  mechanism,  in  ker  ning  with  the 
philosophy  of  the  language,  is  designed  to  provide  substantial  function  at  minimal 
cost,  but  as  these  two  limitations  suggest,  it  is  not  suitable  for  all  exceptional 
condition  handling  situations  As  an  example,  consider  the  position  of  a genera; 
storage  allocator  in  a complex  system  if  it  is  unable  to  satisfy  an  aliocat  n 
request  using  its  own  resources,  it  will  raise  the  'out-of-storage'  condition, 
requesting  other  system  modules  to  release  some  storage.  It  cannot  make  this 
request  via  a Bl  ISS  signal  since  the  current  invocation  of  the  'get-storage'  routine 
will  he  terminated,  and  the  allocator  will  then  have  no  opportunity  to  satisfy  tire 
request  even  if  some  'out  -of-storage'  handler  releases  adequate  space.  The 
allocator  is  forced  to  use  an  explicit  subroutine  call,  implying  that  it  knows  the 
names  of  the  routines  (in  effect,  handlers)  in  other  system  modules  that  can 
potentially  release  storage.  But  this  suggests  that  every  time  a new  module  that 
uses  the  allocator  is  introduced  into  the  system,  an  additional  routine  call  should  Lae 
included  in  the  allocator  to  invoke  this  new  module's  'try-to-free-some-storage' 
routine.  We  see  what  violence  this  does  to  the  specifications  of  the  allocator  by 
introducing  an  awkward  circularity.  By  allowing  resumption  of  the  signaller  upon 
handler  termination,  we  can  eliminate  many  such  structuring  problems.  This  leads  to 
the  MPS  mechanism,  which  we  examine  next. 
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2.2.7  Th©  MPS  Mechanism 

MPS  [Lampson  74]®  solves  the  problems  inherent  in  the  BLISS 
mechanism^  by  treating  handler  invocations  ns  subroutine  calls  made  from  the 
signaller's  context.  The  important  distinction  from  normal  subroutine  colls  is  that 
the  signaller  does  not  know  what  'subroutine'  he  is  invoking.  In  fact.  MPS  specifies 
that  an  ordered  list  of  handlers  be  consulted,  with  each  one  being  passed  the 
condition  name  and  an  argument  record  (In  the  Al  GOL-W  [Wirth  66]  sense) 
composed  of  parameters  supplied  by  the  signaller.  If  a handler  'rejects'  the  signal, 
the  next  handler  in  the  list  is  consulted,  but  if  a handler  corrects  the  condition,  it 
may  resume  execution  of  the  signaller  by  a simple  subroutine  return  (including  a 
return  record,  if  desired)  Finally,  the  handler  may  raise  the  system  signal  unwind, 
which  implies  that  the  (original)  signaller  and  all  'passed  over'  program  levels  are 
about  to  he  terminated.  Fach  such  level  Iras  an  opportunity  to  process  the  unwind 
signal  (by  providing  an  unwind  handler)  after  which  the  level  is  deleted  This 
mechanism  permits  a more  natural  structure  for  the  storage  allocator  example,  one 
that  eliminates  several  of  the  difficulties  mentioned  above  It  also  provides  some 
facilities  that  permit  definition  of  'default'  handlers,  i.e  handlers  that  are  invoked 
only  if  no  higher-level  handler  resolves  the  signalled  condition. 

In  a sense  the  MPS  mechanism  represents  the  "culmination"  of  the  work  in 
sequential  program  exception  mechanisms  since  little  has  been  done  to  extend  its 
applicability.  If  we  review  our  list  of  issues  (section  2.1),  we  find  that  t addre  sses 
most  of  them  quite  well.  T xceptions  are  explicitly  defined.  The  unwind  mechanism 
helps  preserve  abstractions  by  guaranteeing  that  no  executing  context  will  he 
unceremoniously  aborted  by  an  exception.  The  mechanism  meshes  well  witn  other 
language  facilities  and  seems  easily  trai  storable  to  most  conventional  pun  edurnl 
languages,  with  acceptable  cost  Why,  then,  is  it  not  ideal  for  exception  handling? 

^ The  exception  handling  proposals  c I KH’S  have  foo  d the  v.a>  nlr  '•  <.  vr  SA  !a-  ; ;age  [(■-■  i re  j 

' We  should  note  lhal,  contrary  to  tor  lime  seq  r ce  implied  hy  the  y v >. .-  a I ion  of  this  > apte-  the  1 ss  signal 
enable  construct  was  actually  derived  from  tie  WPS  ire-  aosm  with  dehhe’ale  sin:  ' < atons  to  streamline 
impl«*mc»nta  I*  on. 
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Perhaps  the  most  serious  shortcoming  of  the  MPS  mechanism  is  its  faiture  to 
accommodate  shared  abstractions.  When  an  exception  is  raised  in  MPS,  the  only 
possible  source  of  handlers  is  the  dynamic  execution  nest,  i.e.  the  process's  stack. 
I Ins  stack  is  searched  in  l II  0 order  until  a handler  is  located  that  will  'accept'  the 
exceptional  condition.  Hence  there  is  a built-in  assumption  that  the  only  contexts 
in  which  handlers  can  (should)  be  found  occur  in  functions  that  have  been  initiated 
but  not  completed  Yet  we  can  identify  contexts  in  which  the  exception  might  be 
intelligently  handled  but  which  happen  not  to  appear  in  the  current  call  stack.  In 
essence,  exception  transmission  in  MPS  and  all  the  above  mechanisms  is  forced  to 
follow  the  "calls"  hierarchy  [Parnas  74],  yet  there  is  good  reason  to  suppose 
that  other  hierarchies  are  appropriate  as  well.  Indeed,  it  is  the  contention  of  this 
thesis  that  the  "uses"  relation  is  central  to  ex'  epti  n liar  'Img.  and  that  the  ‘Vails" 
relation  has  been  (mistakenly)  applied  instead  because  the  iwo  frequently  coin  ;ide. 
When  sharing  of  abstractions  occurs  the  relations  diverge  and  the  former  becomes 
more  desirable  for  exception  processing  We  will  discuss  the  issue  of  sharing 
further  in  section  3.1.3 

2.2.8  Some  Proposed  Sequential  Mechanisms 

All  of  the  exception  handling  mechanisms  discussed  above  have  been 
implemented  in  at  least  one  system.  We  now  consider  briefly  three  mechanisms 
that,  like  tins  thesis,  are  proposals  Where  implementations  of  those  proposed 
facilities  exist,  they  are  confined  to  experimental  systems  and  are  not  present  in 
generally  available  systems  or  languages. 

2. P.8.7  Parnas's  Proposal 

Parnas  proposes  a mechanism  [Parnas  72c,  Parnas  76]  for  error 
handling  as  part  of  his  formal  method  of  module  specification  [Parnas  72b].  His 
technique  is  to  invoke  externally  defined  error  subroutines,  which  lu1  views  as 
analogous  to  hardware  'traps'.  Thus  each  function  of  a module  includes  as  part  of 
its  specifications  a list  of  names  of  subroutines  (which  the  user  of  the  module  must 
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provide)  and  defines  the  conditions  under  which  each  such  routine  will  be  (.ailed 
This  approach  addresses  several  of  our  exception  handliny  issues  (section  2.1) 
nicely.  Exceptions  are  explicitly  and  formally  specified  and  are  closely  allied  with 
levels  of  abstraction.  Because  errors  (Parnas  also  uses  the  term  '‘undesired 
events")  are  handled  by  subroutines,  control  may  return  to  the  detecting  module 
after  error  processing  has  completed  - a desirable  property  Propagation  of 
exceptions  across  levels  is  explicit,  forcing  the  preservation  of  abstractions  at 
each  level.  The  mechanism  is  clearly  language-independent  and,  because  of  its 
formal  specification,  likely  to  be  verifiable  as  well.  Parnas  also  recognizes  the 
value  of  the  "uses"  hierarchy  in  preference  to  the  "calls"  hierarchy  Indeed,  many 
of  his  suggestions  are  in  line  with  the  mechanism  we  propose  in  chapter  4. 

Where,  then,  does  Parnas's  proposal  fall  down?  Primarily  in  the  absence  of 
specifics.  While  advocating  the  "uses"  hierarchy  for  exception  transmission. 
Parnas  gives  no  details  about  the  binding  of  handler  to  exception,  which  crucially 
assumes  a definition  of  the  "uses"  relation.9  lie  also  fails  to  specify  important 
details  of  control  flow,  eg  how  the  choice  is  made,  after  handler  completion, 
whether  to  resume  the  signaller,  abort  the  signaller,  or  retry  the  (failing)  operation. 
It  is,  therefore,  impossible  to  assess  fully  the  merits  of  Parnas's  proposal,  and  we 
must  regard  Ins  exception  handling  mechanism  as  incomplete.19 

2. 2.8. 2 Goodenough's  Proposal 

Goodenough  [Goodenough  /5]  proposes  a facility  that  in  many  ways 
closely  parallels  the  MPS  mechanism  discussed  above.  Conditions  are  explicitly 
declared  language  entities  and  are  raised  by  one  of  several  special  statements. 
These  statements  define  the  resumption  requirements  of  the  signalling  context  and 
are  designed  to  he  checkable  nt  compile-time  Goodenough  also  predefines  several 
special-purpose  conditions  lor  signalling  loop  termination,  default  handler  invocation, 


9 His  notation,  however,  suggests  that  at  most  one  handler  is  bound  to  each  e»ception,  a restriction  we  strongly 
oppose.  See  sections  3.1.3  and  4 6. 

^ Wa^sPffnan  [Wa^'-piman  77]  has  p» tended  the  ideas  of  Par nas  along  lines  somewhat  similar  to  our  flow 
conditions  (chapter  4),  hijt  relies  solely  on  the  ''calls’'  hierarchy 
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unwind,  and  other  exceptions.  Unfortunately,  the  interaction  of  these  many 
in  conditions  is  difficult  to  understand,  although  their  intended  purpose  is  to  simplify 

control  flow  and  enhance  clarity.  We  believe  that  Goodenough's  mechanism,  while 
properly  limiting  implicit  propagation  of  conditions,  fails  to  impose  adequate 
constraints  on  the  actions  that  handlers  mav  take,  particularly  with  respect  to 
control  flow.''  Because  it  follows  the  MPS  approach  of  lining  the  dynamic  context 
stack  as  the  sole  source  of  handlers,  Goodenough’s  proposal  suffer'  many  of  the 
same  disadvantages  with  respect  to  shared  data  structures.  In  addition, 
Goodenough  does  not  permit  the  passing  of  parameters  to  handlers  (essential  in  our 
view),  though  fie  recognizes  the  desirability  of  doing  so  and  acknowledges  the 
deficiency  of  his  mecharrsm  in  this  respect 

P.P.8.3  Recovery  Blocks 

One  other  proposed  mechanism  should  he  noted,  though  its  goals  are  rather 
different  from  those  of  the  mechanisms  previously  discussed  The  'recovery  block' 
approach  of  Horning  et  al.  [Horning  74,  Randell  7 5]  permits  the 
specification  ol  an  'acceptance  test1  for  a body  of  program  text  It  the  test 
succeeds,  well  and  good,  hut  if  it  fails,  an  'alternate  block'  es  invoked  and,  upon  its 
completion,  the  acceptance  test  is  performed  again  This  cycle  continues  until 
either  the  test  succeeds  or  all  alternate  blocks  have  failed,  in  which  case  the 
'failure'  condition  is  propagated  to  the  enclosing  recovery  block  scope.  One  key 
point  must  be  ol  sc'vnl,  however  alternate  blocks  are  entered  with  the  program 
state  identic.il  to  that  which  existed  at  entry  to  the  primary  (or  previous  alternate) 
block  Thus  all  record  of  a failing  block's  execution  is  obliterated,  (tfficient  means 
(or  dome)  so  are  discussed  in  [Horning  74])  We  see  therefore,  that  alternate 
blocks  are  not  'handlers'  in  the  sense  of  MRS  or  Bl  ISS,  since  the  program  state  that 
led  to  the  failure  of  the  acceptance  test  has  been  lost  It  is  clear,  then,  that 
recovery  blocks  are  not  really  intended  ns  an  exception  handling  mechanism. 
Indeed,  the  proponents  of  this  facility  are  primarily  concerned  with  capturing 
'residual  software  errors'  (hugs),  not  with  handling  unusual  conditions  that  the 
software  may  legitimately  detect 

^ Spec  f.cally.  1 sa  n fl  I ■ s r^ay  Ca  . *■  thn  ■ f Von  of  aC  'Cng  t’>n  s g.'a’hng  conta»U  • an  unnnrn.^a.y  a rl  rCvof*.  otjs 
f.nn.l  m in  our  vr*w  (Ana  <.»•  I n fl  9.) 
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2.3  Parallel  Program  Mechanisms 

We  now  turn  our  attention  to  existing  structures  for  handling  exceptional 
conditions  in  a parallel  program.  PL/I  has  already  hern  mentioned  as  one  of  the  few 
languages  that  attempts  to  combine  sequential  and  parallel  condition  handling.  We 
shall  see  that  parallel  and  sequential  program  mechanisms  have  historically 
appeared  fundamentally  different,  and  that  no  real  attempt  has  yet  been  made  to 
combine  them. 

We  should  recall  the  remarks  of  chapter  1 about  flip  differences  between 
normal  interprocess  communication  and  exceptional  conditions.  The  distinction,  once 
again,  is  only  a matter  of  degree.  In  a highly  parallel  system  with  only  occasional 
interprocess  communication,  oi ery  such  transaction  might  be  regarded  as  signalling 
an  unusual  event  On  the  other  hand,  communication  may  be  frequent  with  only  a 
small  subset  of  the  interactions  reflecting  unusual  events  In  addition,  the 
interactions,  though  frequent,  may  have  little  or  no  relationship  to  the 
comput ation(s)  in  progress  at  the  instant  of  communication.  Because  of  these 
vague  distinctions,  identical  mechanisms  have  generally  been  used  for  both  normal 
and  exceptional  interprocess  communication,  and  our  mechanism  will  be  equally 
applicable  as  well.  ^ Accordingly,  we  survey  the  major  communication  mechanisms 
in  use,  concentrating  on  their  behavior  as  exceptional  condition  mechanisms. 


2.3.1  Polling 

Polling  is  perhaps  the  simplest  form  of  interprocess  communication  Processes 
using  polling  share  a data  structure  in  which  they  set  status  indicators  from  time  to 
time.  Status  enquiries  are  made  by  explicit  tests  of  the  indicators,  and 
synchronization  is  achieved  by  busy  waiting  Polling  can  be  used  in  any  system  in 
which  (conceptually)  parallel  tusks  and  shared  data  are  supported  and  thus  is  easy 
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to  implement,  though  frequently  expensive  1 1 1 use.  The  objections  to  polling  as  an 
exceptional  condition  mechanism  ore  analogous  to  those  mentioned  above  in 
sections  2.2.1  and  2 2.2.  No  explicit  structure  is  present,  except  that  provided  by 
other  language  mechanisms,  so  the  identification  of  conditions,  signallers,  and 
handlers  is  purely  ad  hoc.  1 he  same  holds  for  the  techniques  used  to  pass 
parameters  between  signaller  and  handler  and  to  resume  execution  ^conditionally) 
upon  termination  of  the  handler.  Furthermore,  the  implicit  access  by  muttiple 
processes  to  the  shared  data  structure  enormously  complicates  understanding  and 
verification  of  the  behavior  of  the  entire  program  Finally,  unless  the  processes 
possess  and  share  knowledge  about  the  underlying  scheduling  policies  of  the 
system,  they  will  almost  certainly  waste  processor  time  using  busy  waiting  to 
achieve  synchronization  of  signaller  and  handler.  In  short,  polling  is  a serious!*' 
flawed  exceptional  condition  handling  technique. 


2.3.2  Interrupts 

Polling  depends  on  tire  eventual  inspection  of  shared  data  structures  to 
initiate  changes  in  control  flow  An  alternate  method  is  to  force  the  change  by 
means  of  an  interrupt,  generated  at  the  time  an  exceptional  condition  is  detected. 
This  is  tiie  traditional  method  used  in  hardware;  a peripheral  device  notifies  a 
processor  of  an  exceptional  condition  (e  g.  i/0  completion)  by  causing  a forced 
branch  to  a predoti  rmined  location  This  differs  crucially  from  flip  forced  branch  of 
section  2.2.2  in  that  the  processor  state  at  the  time  of  the  interrupt  is  saved  as  a 
side  effect  of  the  branching  action  In  addition,  seine  of  flint  state  is  replaced  with 
new  values  taken  from  an  area  of  memory  associated  with  the  interrupt  location 
When  the  interrupt  handler  has  completed  its  work,  the  saved  state  may  bo 
reloaded  and  the  interrupted  program  resumed. 

Interrupts  have  two  evident  advantages  over  polling  Tirst,  the  handlers  are 
clearly  identifi  tble  and  localized  Second,  the  need  to  test  continually  for  the 
presence  of  the  exceptional  condition  is  eliminated,  substantially  reducing  overhead 
cost.  However,  several  problems  remain  The  shared  data  structure  that 
complicates  verification  is  still  necessary,  since  parameters  are  not  usually  passed 
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with  the  interrupt.  Also,  the  possibility  of  arbitrary  interruption  is  intolerable  to  most 
programs;  critical  sections  usually  exist  during  which  a crucial  property  (invariant) 
assumed  by  the  Interrupt  handler  does  not  hold.  This  leads  to  the  notion  of 
temporarily  disabling,  or  masking,  interrupts.  In  this  way  a program  can  prevent 
interruptions  until  it  explicitly  enables  them.  But  then  what  happens  If  two 
interrupts  arrive  during  a masked  period?  Are  they  queued  separately  or  are  they 
merged  Into  one?  If  the  latter  (most  common  in  hardware),  how  does  the  handler 
eventually  discover  that  fact?  And  If  the  former,  where  are  the  queues 
constructed  and  how  are  they  managed?  Is  it  possible  to  mask  each  interrupt 
individually  or  are  they  grouped  into  classes  which  are  masked  or  enabled  as  a 
whole?  If  the  latter,  is  the  grouping  static  or  dynamic?  These  design  issues  and 
others  have  been  extensively  studied,  since  interrupts  have  been  present  in  nearly 
every  computer  designed  in  the  last  15  years.  Some  are  appropriate  for  an 
exceptional  condition  handling  mechanism  with  the  properties  we  seek,  others  are 
not  We  will  close  our  discussion  of  interrupts  by  examining  one  useful  extension  to 
the  basic  notion 

Interrupts  in  their  simplest  form  cause  the  flow  of  control  to  be  transferred  to 
a particular  physical  location,  without  any  regard  to  the  executing  process.  It  Is 
frequently  more  useful  to  be  able  to  force  a transfer  of  control  to  a particular 
virtuaj  location  within  a specific  process.  That  Is,  the  interrupt  Is  sent  to  a process 
(which  is  presumably  interested  in  handling  it),  not  to  a processor.  This  notion  is 
often  available  in  software,  but  rarely  in  hardware,  because  of  the  absence  (in 
general)  of  the  notion  of  'process'  at  the  hardware  level.  However,  it  is  obvious 
that  an  interrupt  of  this  style  is  a much  truer  form  of  interprocess  communication 
than  the  basic  one  previously  discussed.  In  fact,  it  leads  naturally  Into  message- 
based  communication,  ‘ 


2.3.3  Message  Systems 

Message  systems  dispense  with  the  notion  of  (physical)  processors  entirely, 
and  view  communication  as  occurring  between  either  processes  or  intermediate 
objects  called  mailboxes.  Message  system  facilities  are  quite  diverse 


SEC  2.3 


FAHALLEL  FF'  GRAM  MECHANISMS 


[Brinch  Hansen  71,  Wulf  78]  and  actually  span  a wide  space  extending 

from  generalized  polling  to  generalized  interrupts.  However,  there  are  two  important 
aspects  of  exceptional  condition  handling  embodied  in  nearly  all  message  systems: 
explicit  parameter  passing  from  signaller  to  handler,  and  Implicit  queuing  (instead  of 
merging)  of  distinct  signals  By  restricting  the  flow  of  data  between  processes  to 
the  well-defined  channels  of  the  me-  sage-passing  mechanism  we  remove  many  of 
the  harriers  to  verification.  If  we  use  a ne  ssage  system  in  which  the  handler 
blocks  its  execution  until  awakened  by  the  arrival  of  a message  (i  e.  it  is  nor 
interrupted  when  a message  arrives,  but  r ist  explicitly  ask  the  system  for  any 
outstanding  mi  s)  wt  r localize  for  verification  purposes  the 

interprocess  communi  at  ion  Hetamioy  the  identity  of  ndividual  an  ving  messa  les 
also  helps  us  prove  that  tl'<-  pi  e sps  sy  ■ hronize  in  part  ular  ways  In  short,  a 
message  system  appears  to  have  the  most  s.  it  able  collection  of  properties  (among 
existing  mechanisms)  for  a i aralh*  <*  <■  'll  -.rendition  handling  fatality. 

Some  difficulties  remain,  h v.v««ver  Mar  y message  *.\  stems  provide  only 
unidirectional  message  flow,  with  no  f . . ui  ' for  an  implicit  reply  upon  completion  of 
the  handler's  (receiver's)  act.  1 In  f .'  • • i -h  n of  resumption  of  the  signaller 

must  be  built  explicitly  with  a < I '<e  re  p ,th‘  to  tin  signaller.  As  we  have 
seen,  such  unenforced  explicit  strn  -ji"s  me  ti  nder  tn  understand  and  verity  than 
mer  hnnisms  which  embody  re  .umption  in  P . ri.mti  s More  seriously,  message 
systems  are  traditionally  software  stm  hr-  • supplied  b>  the  operating  system  or 
some  subsystem,  thus  they  are  i>  it  nor.  ■ i , a ailahle  for  use  at  the  hardware 
level  or  within  the  system  itself,  when  mi  h f the  parallelism  is  likely  to  be.  A 
different  technique  must  he  used  within  the  , . stem,  introducing  an  undesirable  non- 
uniformity in  the  exceptional  condition  structure 


2.4  Summary 

As  the  preceding  ecti  ns  •!  >w.  exi-.t  • i lire  t ,,i,",ms  for  handling  exceptional 
conditions  in  sequential  at  I i ..rallel  pr.  ;■  i s differ  ■ onu  !■  rably.  We  observe 
substantial  overlap  h et we  exr  .option  hedling  and  general  communication,  and 
some  of  be  existing  median  ms  cater  more  directly  to  one  than  to  the  other  The 
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mechanism  proposed  in  chapter  4 respects  that  overlap  while  recognizing  that 
certain  concessions  must  be  made  if  the  goals  of  section  1.3  are  to  be  attained. 
Now  that  we  have  both  those  goals  end  previous  exception  handling  attempts  in 
mind,  we  can  proceed  to  a synthesis  that  will  yield  our  proposed  mechanism. 


Goals 


3 

Elaboration  of  the 

In  chapter  1 we  presented  the  goals  . •!  this  thesis.  !h<  car  he  rr  cite  m a 
single  sentence.  We  seek  to  define  a program  stre  tubus  f .<  slit  ft. at  pern  :' 

uniform  handling  of  exceptional s,  is  ami  table  to  rig<  . rificattor 

naturally  accommodates  a variet  / of  practical  | ■ : 

Wo  have  seen  how  existing  mechanisms  fail  to  atisfy  these  g ais  a-,  i thus  h- 
acquired  some  ui  oWslanding  of  ttie  un  iesirabte  properties  embodied  in  *.  .... 
facilities.  In  this  chapter  we  establish  the  groundwork  fen  fee  pies'  ntat  •••• 
new  mechanism  that  meets  the  stated  goals 

Throughout  this  chapter  the  dir  s ussion  will  he  at  n ig.neal  anti  inf  or  *pv 
I st|  ning  details  until  subseguent  chapters  Wr  in  I ppl  fic  defii 

for  such  cru  ial  terms  a "context"  " n e’  t n",  x ■ pi  1 mtil 

have  available  to  us  the  structure  of  a particular  language  Chapter  d wit’ 
provide  us  with  that  structure,  until  then,  wo  must  content  ourselves  witli  intuitive’ 
notions  and  somewhat  vague  terminology. 


3.7  Uniformity 

I lie  desire  to  exhibit  a simile,  limb  uiily  applicable  s o nam  m derives  boi, 
attitudes  about  program  structuring  We  prefer  to  build  programming  systems  ! om 
small  number  of  primitive  concepts  and  to  obtain  expressive  power  from  tbeir 
interactions.  Modern  design  precepts  stress  tire  organization  of  progiamm  , 

■ yet  ms  around  a few  elementary  i ■ m-  true  t vr-  -e  ■ • ; mtu  s arc-  uni  fully  ru  >• 
and  precisely  defined.  These  primitives  then  permit  us  to  huild  * .im;  '■  d 
structures  whose  semantics  are  equally  precisely 

[van  WijngnarHon  r’S]  We  are  moving  away  from  the  1 q itchwerk  gn"t 
pr  oach  to  languagr  lefinitioi  1 | 

systems  assembled  from  disparate  parts  wb  isn  mter,a  "s  are  j<«  mod 
froguontly  clash  [IbM  /O].  The  mechanism  of  this  thesis  is  intended  to  be  no 
primitive  semantic  element  of  a modern  programming  b-m  arid  ay  "P"  ' hie 
to  stilt  It  into  the  quilt  of  some  • xh  ti  g langna  M’S. 
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3.1.1  Choice  of  Language 

We  were  careful  in  the  preceding  paragraph  to  use  tire  term  "programming 
systems"  because  we  are  deliberately  proposing  a mechanism  that  extends,  In 
many  ways,  directly  to  the  hardware  level.  As  was  stated  in  section  1.3.2,  the 
implementation  may  vary  with  the  system  level,  but  this  does  not  concern  us. 
Conceptual  uniformity  is  our  goal,  with  identical  semantics  regatdless  of 
implementation  level  and  technique.  However,  the  primary  application  of  this 
mechanism  will  be  within  programming  languages  (though  not  necessarily  application- 
level  programming  languages),  and  therefore  the  bulk  of  the  presentation  in  this 
thesis  will  be  expressed  in  programming  language  terms.  To  do  so,  of  course,  we 
will  need  a language  consistent  with  the  precepts  mentioned  above.  Several 
languages  would  be  adequate  for  our  purposes;  the  fundamental  characteristic  we 
require  is  encapsulation.  This  principle,  also  known  as  information  hiding 
[Parnas  72a]  or  necessary  access  ("need  to  know"),  stales  that  programs 
receive  only  the  minimum  amount  of  information  necessary  to  perform  their  specified 
functions.  Founded  on  this  principle  is  the  program  structuring  methodology  known 
as  modular  decomposition  [Parnas  72d],  which  groups  a data  structure  and  the 
functions  that  manipulate  it  into  a single  entity  called  a module  The  behavior  of  the 
functions  is  precisely  specified  in  terms  of  abstract  operations  on  the  data 
structure;  no  information  about  thn  implementation  of  these  operations  or  the 
representation  of  the  manipulated  structure  is  ever  provided  to  a user  of  a module. 
Because  we  are  concerned  with  the  semantic  integrity  of  our  exceptional  condition 
mechanism,  we  want  to  embed  it  in  programming  languages  that  stress  abstract 
semantics  rather  than  representational  issues,  languages  that  prevent  the  spread 
of  representation  information  (and  thereby  permit  considerable  flexibility  in  the 
choice  of  implementation)  are  thus  well-suited  to  our  purposes. 

Given  a choice  of  several  acceptable  languages,  we  see  no  reason  to 
construct  a hypothetical  one  expressly  for  the  purposes  of  this  thesis.  We  will  use 
Alphard  [Wulf  76a]  for  several  reasons: 

1)  it  supports  the  notion  of  encapsulation  directly  (through  forms), 
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?)  it  addresses  the  issue  o<  verification  (see  3 2,  below), 

3)  it  js  not  yet  completely  specified,  hence  our  proposal  may  be  of 
practical  value  to  its  contiiunny  development. 

Tins  last  reason  has  two  distinct  facets.  By  < usting  our  proposal  in  the  context  of 
an  incomplete  language,  we  may  suppress  or  alter  details  that  are  cot  of  central 
importance  to  our  mechanism  At  the  same  time,  we  nay  si  - fly  r.»  itairi  properties 
for  lanquaije  elements  that  are  as  yet  undefined  (e  u parallelism).  In  both  v/nvs  we 
hope  to  contribute  to  the  process  of  refining  a new  lanmiane's  specifications 
without  doing  violence  to  any  of  its  essential  netoii', 


3.1.2  Propagating  Exceptions 


A basic  reason  for  the  existence  of  ext  optional  conditions  is  the  realization 
that  the  program  context  in  which  an  unusual  evi  nt  occurs  or  is  detected  may  not 
be  the  best  context  in  which  to  process  it.  Consequently,  this  unusual  c ondition  is 
given  a name,  an  exception,  and  the  knowb’d  i>  that  it  has  been  deb  < t ed  pusses 
from  the  context  that  made  the  discovery  to  the  context(s)  that  can  process  it. 
Generally,  the  point  of  detection  and  the  point(s)  of  processing  reside  in  distinct 
modules,  so  that  the  act  of  "raising  the  exception"  c arises  information  to  flow 
between  modules.  In  view  of  the  comments  of  the  preceding  sec  tion,  we  should 
require  that  this  information  he  consistent  with  the  abstractions  involved;  that  is, 
the  detecting  module  should  expiess  the  exert  tional  condition  in  terms  of  tire 
abstraction  the  module  defines. 


It  may  not  be  possible  for  the  recipient  of  an  exception  to  process  the 
c erudition  completely.  Often,  the  occurrence  of  the  exception  may  have  a serious 
effect  on  its  behavior,  forcing  it  to  raise  an  ex<  up  tier,  as  well  In  accordance  with 
flip  principle  of  maintaining  abstractions,  this  •-<><. ond  exception  must  be  c xptessod 
m terms  of  the  recipient's  abstraction;  it  cannot  simply  restate1  the  condition  raised 
by  the  original  detecting  module.  Thus,  as  a condition  crosses  an  "abstraction 
boundary"  (i.e.  a module),  it  must  be  transformed  to  reflect  the  external  semantics 
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and  specifications  of  the  module  it  is  leaving.  In  this  way,  representational 
information  remains  captive  within  a module 

We  can  see  an  obvious  analogy  in  the  well-known  problem  of  providing 
intelligible  run-time  diagnostics  tor  a high-level  programming  language.  Hardware- 
detected  exceptions  will  be  expressed  in  terms  of  addresses  (the  abstraction 
provided  by  the  hardware),  which  generally  have  no  meaning  to  the  high-level 
language  user.  It  is  the  responsibility  of  the  language  "module",  which  implements 
(through  a compiler  and  run-time  system)  the  abstraction  inherent  In  the  language 
semantics,  to  transform  such  addresses  into  the  control  and  data  structures  of  the 
program  being  executed  Most  conventional  systems  transtorm  only  a subset  of  the 
exceptions  the  hardware  can  raise,  and  handle  the  remainder  by  printing  a cryptic 
message  (in  terms  of  the  abstraction  supplied  by  the  hardware)  and  terminating 
execution  Should  the  programmer  be  unfortunate  enough  to  receive  such  a 
message  (e.g.  "Fatal  Run-time  Frror:  Memory  Parity  Error  at  472106"),  he  cannot 
assign  any  meaning  to  it,  since  it  is  not  expressed  in  terms  of  the  abstraction  (the 
language)  he  perceives.  Equally  cryptic  messages  can  arise  from  software- 
detected  exceptions  as  well;^  in  both  cases  an  abstraction  has  not  been 
maintained. 

This  example  Illustrates  two  errors  in  the  design  of  the  language  module:  its 
failure  to  express  an  exception  in  terms  of  the  proper  abstraction,  and  its  unilateral 
decision  to  terminate  execution  rather  than  propagate  a condition.  We  have  just 
seen  how  useless  an  exception  expressed  in  improper  terms  can  be,  but  we  should 
understand  that  the  failure  to  raise  an  exception  at  all  is  just  as  serious. 

Suppose  that  our  hypothetical  programmer  has  implemented  a data-base 
system  using  the  given  high-level  language.  Because  he  is  concerned  with  high 
reliability  in  his  system,  he  has  gone  to  considerable  lengths  to  organise  tils  data 
structures  to  permit  recovery  from  various  failures.  However,  he  depends  upon  the 
language  to  provide  him  with  exceptions  ‘or  all  conditions  that  It  cannot  handle 
internally.  In  the  context  of  our  previous  example,  we  will  assume  that  it  the  data- 


f g "Negative  argument  to  LOG  routine  h*ggered  by  the  sour  re  level  e*pfe*sion  Xt(1./3.),  vvhete  denotes 
exponentiation  and  X is  negative. 
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hasp  system  is  informed  (by  an  exception  notification)  that  a particular  datum  has 
been  destroyed,  it  may  be  capable  of  reconstructing  that  datum  either  from 
redundant  data  or  recomputation.  If  it  can  do  so,  the  fact  that  a datum  was 
(temporarily)  destroyed  will  be  completely  hidden  within  the  data-base  system  and 
no  exception  will  be  transmitted  to  the  user  of  that  system.  Should  the  data-base 
system  be  incapable  of  repairing  the  damaged  item,  it  will  probably  report  to  its  user 
some  exception  in  terms  of  the  abstraction  the  user  sees  (eg  " I ransachon  to' 
March  15,  19fd,  inadvertently  destroyed")  All  of  this  clearly  do- ruble  I. chav  <r 
depends  crucially  on  the  language  module  reflecting  all  exceptions  to  its  user  (the 
data-base  system)  in  terms  that  the  system  recognizes. 


3.1.3  Associating  Detection  and  Processing  of  txccptions 

We  have  already  emphasized  that  an  e*:  option  will  innorally  be  pro.  •■•  sod 
outside  the  module  that  raises  it  A module'  that  i.  i\es  an  exi  option  will  therefore 
not  possess  the  knowledge  to  determine  what  program  context(s)  should  r < c oive 
notification  of  the  exception,  indeed,  it  will  not  r . on  ho  able  to  name  such  possible 
contexts.  The  exceptional  condition  mechanism  is  therefore  responsible  for 
transmitting  the  exception  to  the  proper  context(s)  furthermore,  the  module 
raising  the  exception  may  need  to  synchronize  with  the  context(s)  processing  the 
exc.C'ption  in  order  to  del  ei  mine  when  and  if  the  difficulty  has  been  resolved. 
Obviously,  the  mechanism  must  assume  responsibility  here  ns  well,  since  the 
detecting  module  cannot  explicitly  name  or  enumerate  the  contexts  with  which  it 
must  synchronize.  The  means  by  which  the  exception  mechanism  performs  these 
vital  services  are  described  in  chapter  d,  we  concern  ourselves  here  with 
several  implications  of  our  chosen  methodology  on  the  | m ('cities  of  this  mechanism. 

Informally,  we  can  say  that  the  context.',  that  regime  notification  when  an 
exception  arises  in  a given  abstraction  are  precisely  the  users  of  that  abstraction. 
A careful  definition  of  "users  of  an  abstraction"  depends  on  specific  language 

' Consider  the  havoc  that  the  languaap  nu  dp  may  vvroak  if  il  ah  Us  p.p.-ution  of  the  data  hasp  system  in  'pad 

of  raiding  an  ox  option.  Crucial  files  of  II. o data  t«v>e  • » , t #»  loft  .in  »t  .slate.  ; f*  'ally  r an  - -g 

fur  flier  erroneous  t ohavior  wl»en  the  data  I i -o  ' , tern  t*  later  r<  tarterf 
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constructs,  but  wo  can  give  a characterization  that  depends  on  methodological 
views  alone  We  consider  a context  to  be;  using  an  abstraction  (or  module)  if  it 
possi  ibility  1 ke  t ided  by  that  abstraction.  This 

definition  is  not  quite  vacuou  ; it  peri  ts  a text  to  be  using  a module  even 
though  that  ontexl  , t b<  rrently  iting  "Use"  in  this  sense  thus  has 

both  a static  and  a dynam  • component,  a >ntext  rnay  be  an  executing  program 

that  can  invoke  the  given  lie  cr  it  i o 1 * u.ita  structure  that  is  implemented 

in  terms  of  l<  a contexl  ned  by  control  flow,  the  latter 

is  one  defined  by  data  flow,  and  ol  tern  lated.  In  more  careful 

terms,  a context  Is  using  a r i;  [ s-.es  ns  a > usability  [l  amp  son  69] 

for  that  module  Thus,  in  < dor  for  ' ■ e • . ! ri  mechanism  to  notify  the 

appropriate  « ontexts  of  an  ex,  epb  -n  r 1 l y .uh  M,  it  must  he  able  to  locate 
all  capabilities  for  module  M “ This  doi  ; ly  that  it  will  necessarily  reflect  the 

exception  to  all  contexts  holding  so  n • ability,  but  merely  that  all  such 

contexts  will  initially  be  considoied  eligible 

It  is  this  notion  of  f c .<  -s:  i r • ty  ' tnat  defines,  for  our  purposes, 

the  "uses"  contexts  are  sharing  an 

abstraction  if  a h nos*.  a al  t y '<  - n We  establish  the  "uses"  relation, 

not  the  "calls"  relation  as  thi  ha-  s U exc-i*  >n  transmission  by  our  mechanism, 
it;  see  the  diffei  idi  r the  following  situation  (which 

reappears,  thinly  disqti"  ed.  it  s-  -r  d p • in  - u l > ■- >.  juent  chapters). 

Suppose  wo  | five  a .sic,.  ;■  »l.  • picv  les  an  abstraction  called  a 

"pool".  This  poo!  s shared  try  a numbe*  » > wh  > may  or  may  not  be  aware  of 

each  other  s * xr-tee  e.  iupposn  Hot  t itor  defines  an  exception,  "pool- 

low",  that  it  - a .>’5  win  i i-"  1 1 f f o out  r*  ■-  <•-.  an  available  to  satisfy  an  allocation 

request.  Wt  might  .c  . nably  expect  > i h < to  release  some  storage  when  the 

t least,  1 >y  appropriate  compel  t ion 

of  its  privati  data  structures  Thus,  all  m.  s .six  ad  have  an  opportunity,  at  least, 

to  e!  inmate  th  - pi  .v  conrld  >n  h ■ • • i it  r.  dt-i o«  'ed.  Vet  only  one  of  the  users 

will  have  performed  thi  i I that  to  the  detect  on  We  see,  therefore, 
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>,  that  the  "calls"  relation  and  the  "uses"  n lation  do  nut  i on  1.1  le  •:  f • ; 1 1 i , of 

shared  abstractions,  and  that  the  "uses"  relatioi  is  ii -t-i-tiv*-: . . - * ■ , • • 

least  in  this  case,  for  exception  transmission,  hi  I iter  se<  ' mis.  . *t  t 
chapter  7,  we  will  acquire  additional  practical  suppo-t  tor  t is  v. 

3.1.4  The  Role  of  the  Exception  Mechanism 

From  the  preceding  discussion,  it  appears  that  tl  o i i : 
supply  a collection  of  services  that  permit  modules  to  c > , ' • 

and  processing  of  exceptions  among  th.ein  a !ve  • in  :ht-i . > 

jeopardize  (and  indeed  should  encourage  preser-  ••  >n  of  «l 

the  modules  provides.  Let  us  consider,  then,  s am  desial a ri  ■ 
mechanism. 

Modules  that  must  operate  correctly  In  spit . ■’  ■>  pt  d I iv  ■ i m_ 

abstractions  they  use  should  be  designed  with  the  | if  "n  sus|  ■ >• 

[Schroeder  72]  clearly  in  mind  Simply  stated,  tins  principle  asserts  that 
interacting  modules  validate  (in  terms  of  absti  c t specifications  and  insofar  as  is 
possible)  the  transactions  between  them.  Normally,  this  principle  is  applied  at 
function  invocation,  when  one  module  explicitly  < n’K  another.  '**  the  ( a me  i it-  >n 
applies  in  exception  handling  1 he  mm  dull-,  ran  m • in  r-xi  • i ti  - ■ r oi  a-  ini>  at-’i 
with  contexts  that  are  expected  t<  per*  ■’  ;m  * • < -n  > ' ’ ’ behalf  s 

and  certain  actions  on  behalf  of  the  h te  t i • j , f ' . j I wants 

assurances  that  the  contexts  receiving  the  *>  ■>  h-  i -untot  prevent  t from 

resuming  execution;  that  is,  it  expect s tl  <•  m>  l e ■ a b t o > „■  t.  ar  lets  of 

control  during  exception  processing  At  |h-  a * e.  mt»  ; P >'  > to 

receive  notification  of  an  exception  want  a uim  s that  ttiey  will  no  ■ <-d  re  eivo 

control  if  the  exception  is  raised.  We  conclude  lu.it  the  m-  hams  .i  t re  i met 

the  mutually  suspicious  design  of  leH-tar  hug  mediii.  s >n-  1 ust  eat  " ms«  that 

design  at  the  exception  handling  delta'  e 

Ihe  mechanism  must  not  constrain  the  form  ot  t hr  ahstracti.  m a modulo 
designer  chooses  to  define,  ns  long  as  they  me  c.onsis  i nut  with  tin  geneia! 
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methodological  principle  of  information  hiding.  Whether  a module  provides  a 
computational  or  structural  abstraction  is  a matter  for  the  designer,  he  should  not 
he  forced  to  choose  a particular  one  because  of  the  facilities  provided  by  the 
exception  mechanism.  From  this  principle  we  infer  that  the  mechanism  should 
support  with  equal  convenience  exceptions  related  to  flow  of  data  and  control. 

We  expect  to  justify  the  properties  of  the  mechanism  in  terms  of  the 
information  hiding  methodology  We  also  expect  the  mechanism  to  f.t  neatly  nto  the 
embedding  language  and  to  interact  reasonably  with  other  language  properties.  In 
particular,  the  mechanism  must  not  require  the  language  to  provide  specific 
facilities  (eg  synchronization)  for  the  mechanism  alone,  but  it  most  funct.on 
predictably  in  the  presence  of  such  facilities.  Parallel  processing,  shaied  data 
structures,  synchronization  ana  protection  are  all  language  (system)  notions  that 
inevitably  interact  with  exceptional  condition  handling,  and  we  must  demonstrate 
that  the  mechamam  does  indeed  respond  reasonably  to  all  f th use  facilities. 

llie  issues  mentioned  thus  far  in  this  chapter  all  concern  the  requirements 
imposed  on  the  exceptional  condition  mechanism  by  the  assumption  that  it  is  to  be 
embedded  in  a language  supporting  encapsulation  as  a fundamental  design  principle. 
The  generalities  of  this  section  will  be  translated  in  chapter  4 into  specifics  in 
the  context  of  Alphard,  and  the  reader  will  then  be  able  to  judge  whether  the  goal 
of  defining  a uniformly  applicable  exception  mechanism  has  indeed  been  realized. 


3.2  Verifiability 

Of  the  three  primary  goals  established  in  section  1.3,  verification  has  perhaps 
the  most  significant  effect  on  the  structure  of  the  exception  mechanism.  The 
ability  to  verify  programs  in  a particular  language  is  enhanced  by  strong  statements 
about  global  properties  of  the  language,  e g statements  limiting  the  possible  side- 
offects  of  out-of-line  code  When  we  seek  to  extend  that  language  with  an 
exception  handling  mechanism,  we  most  be  careful  not  to  weaken  or  invalidate  any 
of  these  global  assertion*  In  practice  this  means  establishing  strict  rules  for 
access  to  variables  and  transfers  of  control  It  is  often  the  case  that  two  distinct 
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designs  will  supply  essentially  the  same  operational  facility,  yet  one  will  ho  easier 
to  verify  than  the  other.  That  is,  for  the  purposes  of  present-day  proof  technology, 
it  may  be  possible  to  characterize  formally  the  semantics  of  one  mechanism  more 
easily  than  the  other.  In  the  course  of  d,  •ngning  the  mechanism  to  be  presented  in 
chapter  4,  such  situations  have  frequently  arisen.  We  examine  in  this  section 
the  implications  of  the  verification  requirement  on  the  mechanism,  in  chapter  b 
we  pursue  the  details  of  verification  in  the  Menard  context. 


3.2.1  Using  Existing  Language  Properties 

Because  effective  verification,  with  current  technology,  relies  heaviiy  on 
complete  knowledge  of  the  interactions  of  language  facilities,  we  must  approach  out 
verification  requirement  in  the  context  of  a specific,  language,  Aiphard  We  weave 
our  mechanism  into  the  language  by  h o.  -mg  the  semantics  of  existing  pieces  of 
the  language  and  modifying  them  a little  as  possible  In  s-  me  cases  this  produces 
a design  noticeably  different  fe  m one  that  might  evolve  in  the  absence  of  a 
verification  requirement,  but  as  long  as  adequate  function  results,  the  approach 
succeeds. 

Specifically,  we  borrow  heavily  from  the  notion  of  functions.  Since  conditions 
are  detected  and  processed  in  • ate  modules,  we  cannot  generally  expect  to 
have  both  detecting  and  hanilhn  | < io  a ail, able  simultaneously  at  verification  time 
When  we  verify  a module,  we  expo  t to  have  only  a characterization  (in  terms  of 
predicates)  of  the  semantics  of  the  (external)  functions  arid  abstractions  it 
employs.  We  use  those  predicates  as  we  1 t ustruct  verifit  ation  conditions  for  the 
invocations  of  those  functions.  If  the  externally-defined  abstractions  raise 
exceptions,  rt  seems  only  natural  to  expect  a characterization  of  the  semantics  of 
those  conditions  as  well. 

If  we  recall  (from  section  3. 1.4)  that  the  code  to  process  an  exception  is 
required  to  return  control  to  the  module  (function)  detecting  the  t xcepfion,  then  we 
see  a natural  similarity  between  such  code  and  a function  body.  The  essential 
difference  is  that  the  "caller"  (i.e.  the  module  detecting  the  exception)  defines 
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^ what  the  "callee"  (>  e the*  t be  • I the  exception)  may  assume  at  entry 

and  must  ensure  at  exit.  A?  1 *.  tt  1 u • * d.-mg  predicates  are  available  In 

both  modules,  howevei  the  |uite  similar  to  that  for  normal 

functions.  Indeed,  the  pro  ; • . -s  •■*  *•  ; . in  chapter  6 are,  In  essence, 

slightly  altered  versions  of  c on.  e io<  ft'  proof  rules  tor  functions. 

Thus,  the  verification  reg  • t . u , to  choose  an  exception 

mechanism  that  rese-nbles  n invocation  mechanism.  In  so 

doing  we  are  abb;  to  >r  < vt-  * • ' i • • s without  developing  entirely 

new  constructs  or  prt  may  sacrifice  some  efficiency 

in  the  operational  behavior  -f  the  ;h  * we  obtain  instead  an  entianced 

language  that  remains  vt  rh  ahl<  W • t'  <•  • xchange  is  a profitable  one.^ 


3.2.2  Predicates 

Without  upstaging  t fee-  -m  d in  chapters  4 and  6,  we 

present  briefly  t n > t.  >-i-|ike  view  of  exception 

nodule  that  hand 

an  exception,  the  avai'-v  "ty  ol  e l a'  ;s  that  characterise  the  action  to  be 
taker  ' I e xplicit ly , a nd  th a t 

e\  v exception  hav*  two  -o'  «•  ' ,-*tes  These  predicates  are  pre-  and 

po*  condition-,  on  '.he  ,:h-  • i :t  • ••*•  ' le  exception;  that  is,  they  define, 

respectively,  its  <-• ' a t p 1 ef . ••  • • i*  r Ling  cods  lias  been  executed. 

T ro:n  the  viewpoint  -f  ‘ • :l  excepfion,  the  pre-condition  may 

be  assumed  at  entry  and  the  |h  1-c. » must  be  satisfied  at  exit. 

Naturally,  tlu  pre-  n ■ i t-  * lied  by  the  module  defining  the 

abstractin'.-  • ■ * • ’ -a<  con  T he  code  that  handles 

the  pxi  option  will  pre-  : i - - I ms  .is  well,  but  these  predicates  wilt 


In  so  on  »■  • >*  • f ' •’  -r  or  g.rr>e  . me  pntent.al  losses  tn  elfir  ency 

•n  • - >y  U IHe  ’jn ^ ape  n*y  encoutaye  a .ser  to  express 

am  l '•  ' ’'a  wi  at  * e • • • • t ao  * over  “optimisations"  that  restore  iost 

off i .ency. 
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include  information  about  other  abstractions  in  use  besides  the  one  tl  t raised  the 
exception.  I he  proof  rules  ol  chapter  6 relate  these  predicates  to  each  other 
to  establish  the  formal  semantics  of  the  except,  n transmission  and  processing 

Two  side  issues  should  be  briefly  noted,  first,  we  are  using  a proof 
methodology  that  derives  directly  from  li  are's  axiomatic  method.  [Hoare  G:i  j 
We  do  so  because  Alt-hard  does  arid  we  no-  I to  I - • »nsi?  '. ••  t with  the  moth..  hdogv 
of  the  specific  embedding  lan'iunge.  This  rloe  n * imp!,,  1 owever,  that  other 
techniques  are  unsuitable.  Indeed,  there  may  be  no.  • c'egant  formulations  that 
make  verifications  involving  exception  h andling  i .■  < t ave.-iiont.  We  do  not  explore 
that  possibility  here,  satisfying  out  .elves  orvy  tint  a particular  well-known  pro  o' 
methodology  can  be  used  to  verify  pro  r ms  , ->.r nj  this  mechanism. 

Second,  we  should  also  note  that  the  specific  form  of  the  predicates 
mentioned  above  d>  i ends  on  other  Inn  nmgp  facilities  If  the  language  provides 
machinery  for  explicit  state  characterization  of  abstractions,  the  predicates  will 
very  likely  be  expressed  in  term--  of  such  states  Otherwise,  the  state  information 
will  be  implicitly  encoded  in  the  data  stru  • ires  used  to  implement  the  abstraction, 
and  the  predicates  will  reflect  tl  so  civ  oda  is  IT  re  is  disagreement  among 
researchers  regarding  the  value  of  explicit  state  characterizations  for  verification 
purposes;  we  do  not  pursue  that  issue  here 

3.3  Adequacy 

Since  we  claim  that  the  mechanism  of  chapter  4 is  adequate  for  the 
solution  of  practical  problems,  we  n.  ed  a collet  tior>  of  1 ul-wotld  exception  handling 
problems  to  use  ns  examples.  These  examples  should  demonstrate  the  scope  of 
the  mechanism's  power  and  should  include  me  problems  that  cannot  be  solved 
reasonably  with  the  existin  i mechanisms  discussed  in  chapter  2.  Let  us  briefly 
examine  several  such  problems,  all  of  winch  art*  treated  in  detail  in  chapter 

y 

I|  'or  / rf«  !r,Vos  U’C*  * ‘ .i  km  »t*  'y  1 ,»  Hadt'OrdSl  e*CC*ption  Kvidl-ng  pf ObJpLTlS 

f * 'J  .**  " " <M'<  OV  «M  (l  >•/*,  tie  ' Xl  ;.t  .VIALft  ! 1 »)  Wf!! 
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3.3.1  Memory  Data  Error 

General-purpose  computing  systems  rarely  handle  memory  errors  in  an 
intelligent  manner.  Typically,  a memory  error  within  a user  program  causes  that 
program  to  be  stopped  and  receive  a message.  A memory  error  within  the  operating 
system  generally  induces  a crash.  (We  have  already  discussed  the  undesirability 
of  such  behavior  in  section  3.1.2.)  Special-purpose  systems  have  developed 
particularized  mechanisms  for  recovering  from  memory  errors,  but  such  mechanisms 
rely  on  the  structure  of  the  application,  not  general  principles  of  program 
organization  and  information  flow  We  want  the  facilities  of  the  exception 
mechanism  to  encourage  coverage  of  detected  errors  (both  hardware  and 
software).  Perhaps  the  lack  of  an  adequate  mechanism  has  fostered  the  defeatist 
approach  that  is  embodied  in  most  present-day  systems. 


3.3.2  Resource  Allocation  Failure 

The  issues  related  to  exception  handling  in  a resource  allocator  (e.g.  a 
primary  memory  allocator)  have  been  briefly  mentioned  in  section  2.2.6.  We  may 
summarize  the  discussion  by  identifying  three  distinct  exceptions  that  an  allocator 
might  reasonably  raise  and  observing  their  different  properties 

In  the  course  of  satisfying  an  allocation  request,  the  allocator 
may  detect  that  its  resources,  while  adequate  to  meet  the 
current  request,  are  running  low.  Such  a condition  should 
probably  be  propagated  to  all  contexts  where  resources  might 
conceivably  be  made  available  to  the  allocator.  Vet  there  is  no 
reason  to  suspend  the  current  allocation  request  while  the 
condition  is  being  handled;  the  two  actions  are  logically 
independent  and  should  proceed  (conceptually,  at  least)  in 
parallel. 
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1 he  allocator  may  fiml  it  impossible  to  satisfy  a rest-  srt  ' re  ine-.t 
and  may  raise  a condition  expressing  . urgent  need  for  storage. 
Naturally,  the  request  will  remain  ;a  >,  imq  while  tliir  exception  •? 
being  processed 

The  allocator,  even  after  raising  die  previous  condition,  may  riot 
possess  adequate  resources  to  defy  flit  request.  In  this  iso, 
it  must  raise  an  exception  signifying  its  inability  to  meet  the 
requestor's  demands 


We  note  the  differ* 

among  these  conditions  and  their  handlers  Pnubtioss  we  could  post,  late  tli 
plausible  conriil  ■ ■ > 1 1 w j t t ' • ■ • r a e • ) i t i is 

processing  needs.  Existing  excoj  t ion  handling  media  lisms  do  not  pr-  vice  the 
facilities  required  by  these  various  situations,  we  will  d>  monstrate  in  chapter 
7 that  the  proposed  mechanism  solves  the  nhoentor  problem  completely  and 
na  t orally. 


3.3.3  I /O  Completion 

The  preceding  examples  embody  s;h  u ms  in  which  Hie  exception  being 
raised  is  not  crucial  to  normal  program  behavior  that  is,  if  the  condition  never 
occurred,  the  program  would  execute  just  as  well  (perhaps  better:)  and  terminate 
notmally.  However,  we  can  identify  conditions  that  are  essential  for  normal 
termination,  eg  the  knowledge  that  a previously  initiated  i/o  operation  has 
i ompletod.  By  proposing  that  our  exception  mechanism  provide  natural  mean  ■ of 
handling  conditions  that  arise  during  normal  processing  we  arc  overlapping 
somewhat  into  the  area  of  general  inter-program  communication.  We  do  not  claim 
that  our  me  hanism  is  adequate  for  general  i iinnuinicaPeo,  hut  we  observe  that  it  is 
sufficiently  robust  to  handle  situations  in  the  gray  area  between  exceptions  and 
communication  We  consider  an  example  from  this  domain. 
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Suppose  we  have  e co'  notion  of  ; ocessos  that  rmunt  ain  a display  of  various 

quantities  ■ n uti  d fr<  , , I by  tal  si  sors.  Such  a collection 

might  be  part  of  an  oircraft  cot  '•  ystor,  N-  * dly,  s >m~  quantities  (e  g altitude) 
are  more  crucial  than  others  ( s cabin  b -mpr,-  ature)  and  consequently  are  to  be 

recomputed  as  scon  as  now  sensor  lata  rnvr  . We  may  choose,  for  example,  to 

assign  these  high  priority  computations  to  a .pecifie  subset  of  the  processes, 
allowing  then  to  participate  in  the  less  mv  ant  reputations  only  when  they  have 
fulfilled  their  primary  revpons'h a. ties.  Sliotml  such  processes  be  performing  low- 
priority  calculations  when  new  sensor  arrives,  we  will  want  them  to  switch 

back  to  high-priority  calculations  using  the  new  data. 

rhi  ti  m could  be  (and  probab  • rammi  d without  ai  . 

exception  handling  m chanism,  but  w un  loubtedly  use  knowledge  specific  to 
■ i . - I . hronization  facilities 

I he  exception  handling  mechanism  it  chapter  A is  sufficiently  general  to 
permit  this  problem  to  be  solved  without  additional  special  features;  in  particular, 
without  assuming  any  exp!  d t"  c-st  syn  ■ r i u.  ition  mechanisms  By  solving  this 
• m 1 fri  qui  nt  synchronization),  the 

mechanism  demonstrates  its  adequacy  in  necialized  areas  of  inter-program 
communication. 

3.4  Practicality 

Practic.  lity  in  a language  fa  : i l i t y , u ies  the  existence  of  an  efficient 
iiu.  1 1 ■ n i e ’ r . 1 1 1 i vev  nr  rtf  y i ,v  e an  .ivr  notion.  By  removing  a single 

instruction  fern  a pro  jrtiin,  w«  ti.  ' ible  K • ase  its  speed,  but  the  degree  of 

i ru  illy  the  f re  |uency  witn  which  the  instruction  I 

» ■ - pei  econd  is  not 

intere;  ting;  rather,  we  want  to  detei  e fre  pn  n<  f of  • ••  uti  in  relative  to  the 

entire  program  That  is,  we  measure  t speed-up  (or  should  measure  it)  in  terms  of 

the  original  exe  aition  time  this  is  peihrq  s an  oi  mentary  principle,  but  one  often 
ignored  by  programmers,  wlo  have  been  known  to  "opt'ini/e"  sections  of  a program 
th.it  wore  i esponsihle  tor  only  i small  pr  r>  entar;e  of  the  t >tal  execution  cycles 
consumed. 
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How  is  this  observation  relevant  to  exc.i  ption  hanjl  nrj  ’ We  a . rned 

that  the  cost  of  setting  up  handlers  for  co  alite  is  tl  t ir  , . n a 

relative  sense)  not  be  excessive.  In  particular,  for  an  ex-  ep*  >n  ne  -h  . n t tie 
practical,  it  must  be  competitive  with  other  language  far.T-tn  that  r : ' ■ therv  e 

be  used  to  achieve  the  same  effect  If  our  met.n.m  rn  t i exp  ■ • „ . 

programmers  will  find  other  means  to  achieve  the  .••■sired  e“et  p i g.  y 

decreasing  program  clarity  at  the  same  time  0 Thus  we  ''-err  .no  tin  » n>  y 

our  exception  mechanism  as  its  cost  of  use  relative  to  t * . . . i mg  . ,n  i i i . 

The  cost  of  a language  feature  may  he  b divided  inte  two  up  • . i» 

cost  is  incurred  whenever  the  feature  is  used  explicitly,  rich  as  dvn<imr>  r.  ■>tio  i 
of  variables  or  procedure  invot  it  ion  The  second  • , t s fi  ti"  ute  f • ••'  the 

implementation  so  ns  to  lessen  the  first  cost  at  the  tine  th  f<  at  u ■ oltc  illy 

invoked.  Tlu>  distributed  cost  will  he  incurred  whether  or  net  the  f • ■ * 1 1 e >s  e . d 

An  example  is  the  non-local  goto  in  AT  GOT  -00,  winch  whr  n used  n ur-  a 

considerable  expense  (compared  to  a local  goto).  The  variable  display  must  be 
"unwound"  to  restore  the  context  at  the  destination  of  the  goto  However,  the 
very  means  used  to  maintain  the  display  in  order  to  handle  a non-local  go  o 
represent  a distributed  cost  of  tins  facility,  since  additional  processing  is  ru  < ded  at 
block  entry  and  exit  A distributed  cost  is  normally  tfie  result  of  mtera  t,.iy 
language  features  rather  than  a single  facility,  as  in  this  interaction  of  variable 
alloc  ation  and  non-local  transfer  of  control  in  ALGOL-60.  We  will  want  our  except'  n 
mechanism  to  minimize  the  di  f < ts  of  i , entation,  her 
c arefully  control  its  interactions  with  other  language  facilities 

When  the  language  implementor  is  faced  with  alternative  realizations  of  a 
language  feature  that  distribute  the  costs  differently,  he  fends  to  favor  one  or  the 
cither  on  the  basis  ot  anticipated  use.  Such  a b as  can  occur  in  the  design  i roc  > ss 
ns  well  Though  the  exception  handling  mechanism  of  chapter  A may  be 
suitable,  in  principle,  as  a more  general  communication  mechanism,  its  design  has 


* An  • > ample  of  <.uch  behavior  occurs  in  the  'real-world"  use  of  PL/I  Pro.  erlnes  are  an  ••  Oanl  pi  j im 
ifu  1 • ir.g  device,  yet  the  prohibitively  high  cost  of  p - oh  *•  aborts  in  :>nme  nnpVmeMat  ons  o 1 PI  /I  has 

Vi  pr  yrAinmers  to  Avoid  using  them,  The  resultiro  ; ; .n  - have  i»r.rj,  mi*  h,riction  pr . ed’.-tes,  whirh  are 

drff  ■ /U  to  understand  Arid  m,vntaip. 
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been  influenced  substantially  by  its  intended  application  to  exceptions.  Thus,  in 
practice,  it  might  prove  more  costly  than  is  necessary  or  desirable  in  a 
communication  mechanism  The  design  emphasizes  the  view  that  one  is  willing  to 
pay  a considerably  greater  cost  to  transmit  an  exception  than  to  perform  most 
"normal  case"  operations.  Thus  the  specifications  for  the  semantics  of  raising  an 
exception  will  probably  force  a more  costly  implementation  than  that  of,  say, 
function  invocation.  At  the  same  tine,  the  design  recognizes  that  the  action  of 
"enabling"  a handler  (i.e.  providing  a body  of  program  text  that,  in  a particular 
context,  is  willing  to  process  a given  exception  if  it  arises)  is  itself  a "normal  case" 
operation,  and  thus  the  specifications  of  the  mechanism  permit  this  action  to  be 
implemented  reasonably  inexpensively. 

As  a final  observation  on  the  subject  of  implementation  efficiency,  we  recall 
that  the  Implementation  of  the  exception  mechanism  need  net  be  uniform  at  all 
levels  of  a system  The  notion  of  "context"  inside  the  opmating  system  may  permit 
a more  efficient  realization  of  the  exception  mechanism  than  does  an  arbitrary  high- 
level  programming  language  The  specifications  of  the  general  behavior  of 
exceptions  will  be  consistent,  the  language-speoif ic  details  (concerning  interaction 
with  other  facilities)  will  vary  It  is  also  conceivable  that  the  full  generality  of  the 
mechanism  may  not  be  needed  within  a particular  language  (e  g the  ability  to  handle 
exceptions  in  an  environment  that  supports  parallel  processing).  In  such  a case,  a 
consistent  subset  of  the  mechanism's  facilities  may  he  Implemented,  with  a 
potential  saving  in  execution  cost  The  relative  cost  of  the  mechanism  will 
therefore  vary  depending  upon  the  other  facilities  available  in  the  environment;  the 
design  only  ensures  that,  for  a broad  class  of  "reasonable"  languages,  the  relative 
cost  is  acceptably  low. 


4 

The  Mechanism 

This  chapter  concentrates  on  the  specifics  of  the  r rop osed  exceptional 
condition  handling  mechanism.  We  will  examine  the  functional  semantics  of  the 
mechanism  and  relate  them  to  the  facilities  of  a pa'ticular  programming  language, 
but  the  exposition  is  nevertheless  relatively  lanyuage-indep  .-  ndent.  Wo  p pone 
until  chapter  7 examples  that  require  specific  syntax  for  their  presentation. 


4.7  Terminology 

In  preceding  chapters  we  have  used  a variety  of  burns  to  suggest  the 
different  notions  associated  with  exceptional  condition  handling  Before  pro  er  ling 
to  a careful  definition  of  our  mechanism,  we  must  agree  on  a f articular  set  of  names 
to  it) entity  the  concepts  we  will  discuss.  Here  is  a list  of  these  terms  with  their 
intended  connotations: 

l 

Condition  - We  use  tins  term  to  identify  an  exception,  in  the 
sense  ol  section  1.1.  Normally,  conditions  will  have  names 
suggestive  of  their  interpretation  r g 'memory  data  error’  The 
problem  of  name  conflict  will  be  discussed  later  (section  A A I )■ 
Occasionally,  the  term  exception  will  he  used  synonymously  with 
condition. 

Signaller  - A program  that  raises  a condition  is  culled  a 
signaller 4 Generally,  we  will  prefer  to  say  that  a given  pi  gram 
"raises  a condition"  than  to  say  that  it  is  a signaller,  but  we  will 
find  it  convenient  to  have  a single  word  to  contrast  with  'handier' 

(see  below).  'Raiser',  though  consistent,  seems  too  awkward  to 
hear  frequent  repetition. 


Th®  tprm  'signaller*  derives  from  etjHaf  - o hi f?  n ■ ■ * < * - 1 ■ ) 
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Handler  - A piece  of  program  text  that  is  intended  to  process  a 
specific  condition  is  called  a handler.  As  we  shall  soon  discover, 
handlers  may  appear  in  many  places  within  a program,  and  the 
selection  of  the  handler(s)  that  will  actually  receive  notification 
of  a given  condition  (when  it  is  raised)  is  a crucial  issue.  A 
particular  handler  is  associated  (statically)  with  a single 
condition,  although  various  language  mechanisms  may  be 
employed  to  share  program  text  among  handlers. 

Eligible  - When  we  refer  to  a handler  as  eligible,  we  mean  that, 
if  the  condition  with  which  the  handler  is  associated  is  raised  at 
this  instant,  the  handler  will  he  among  those  considered  for 
execution.  Whether  it  is  actually  invoked  depends  upon  the 
selection  policy  for  the  condition,  a property  we  will  cover  in 
section  4.r\1.  A handler  that  is  not  eligible  cannot  be  invoked, 
regardless  of  selection  policy.  The  precise  circumstances  that 
determine  eligibility  are  discussed  in  section  A. 6. 

Context  - Perhaps  the  most  overworked  term  we  shall  need  to 
use  is  context,  lor  the  purpose  of  exception  handling,  we  shall 
normally  apply  the  term  context  to  the  execution  environment  of  a 
piece  of  program  text  that  is  under  consideration  Thus,  for 
example,  we  may  refer  to  the  "context  in  which  the  memory- 
data-error  handler  is  invoked",  i.e.  the  control  operations  and 
data  accesses  permitted  when  the  specified  handler  executes. 
The  terms  "domain"  and  "environment"  are  roughly  synonymous, 
but  generally  refer  to  a broader,  more  slowly  changing  notion  (e  g. 
"protection  domain")  than  "context",  which  includes  the  more 
local  connotation  of  flow  of  control  along  a particular  path.  Our 
most  frequent  application  of  the  term  will  be  to  the  execution 
environment  of  an  eligible  handler. 


A considerable  number  of  additional  terms  will  arise  in  the  course  of  this 
chapter,  but  most  of  them  have  not  suffered  the  extensive  history  of  varied 
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application  ol  ttiose  above.  We  will  borrow  freely  from  Alphard  terminology  to  avoid 
creating  a vocabulary  from  scratch. 

4.2  Relevant  Language  Notions 

Throughout  the  remaining  sections  of  this  chapter,  we  will  examine  the 
detailed  structure  of  the  exception  mechanism.  Although  the  discus- ion  will  use 
Alphard  where  reference  to  language  spec  dies  is  necessary,  we  can  best 
demonstrate  the  language-independence  of  the  mechanism  by  falling  hack  on 
Alphard  details  as  infrequently  as  possible.  In  this  section  we  introduce  some 
programming  language  notions  that  will  appear  frequently  in  the  sequel  and  relate 
them  to  specific  Alphard  constructs 

We  will  use  the  term  module  to  refer  to  the  general  unit  of  program 
s t rue  tut  ihg.  A module  provides  an  ahsti  actly-defined  service  or  implements  an 
abstract  concept,  e.q.  symbol  table,  stack,  or  rectangular  matrix  Modules  provide 
abstract  specifications  of  their  behavior  and  hide  the  Implementation  of  that 
behavior.  1 litis  we  are  directly  borrowing  the  term  'module'  from  Parnas,  as 
previously  discussed  in  section  3.1.1  Modules  are  sometimes  called  types,  type 
modules,  forms,  modes,  clusters,  protected  subsystems,  and  other  tilings,  although 
these  terms  do  not  all  carry  precisely  the  same  connotations,  Depending  upon  the 
emphasis  placed  on  issues  such  as  protei  bon  formal  specification,  verification,  and 
hierarchical  structure,  one  of  these  terms  may  be  more  appropriate  in  a particular 
discussion  than  others.  We  will  skirt  these  semantic  pitfalls  by  using  module 
exclusively,  except  when  we  refer  specifically  to  the  Alphard  construct,  which  is 
called  a form. 

Modules  provide  their  services  to  their  users  through  functions,  in  Pal  lias's 
terminology.  We  will  adopt  the  term  function,  although  we  want  to  strip  away  the 
mathematical  connotations  that  are  inappropriate  for  programming.  Functions  are 
essentially  subroutines^  whose  names  are  known  outside  (i.o.  to  the  users  of)  a 


2 

f von  $uhr online'  has  undosiraMo  c nnotatmns.  Wo  do  not  preclude  macros,  out  of  hop  pf  or  odur  os,  or 
synchronous  mtoiproboss  communication. 
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module.  Specific  languages  may  provide  the  notions  of  "internal"  and  tcrnnl 
subroutine,  our  functions  correspond  most  closely  to  the  latter  However,  tun;  is 

are  more  than  just  externally  visible  subroutine  s,  for  their  behavior  »<•  pr  y 

specified  to  tfie  user  in  terms  of  the  abstraction  implemented  by  the  module 
Alphard  also  uses  the  term  function  for  tins  notion,  and  thus  our  u< 
specific  terminology  coincide. 

The  concept  of  sharing  is  fundamental  to  the  handling  of  ixn  tn 
conditions.  Issues  related  to  sharing  arise  comn  , in  di: 
system  facilities,  for  example,  whether  or  not  two  users  may  share  a o 
file,  a page,  a peripheral).  Implicit  in  these  disc  us-. ions  is  the.  conc.r  pt  >f  u 
tiiore  is  (say)  a single  notion  'file',  but  many  instances  of  that  notion,  some  t w:  i 
may  themselves  be  shared.  Translating  this  into  our  previous  termuiol- 
provides  an  abstraction  which  may  be  instantiated  many  times,  f ach  i u <• 
he  available  (accessible)  in  one  or  more  contexts,  in  the  sense  of  i 
example,  a file  containing  accounting  data  m.  iht  be  accessible  only  in  co  -<*  *-ts 
exist  within  the  module  providing  login/logout  functions. 

When  we  instantiate  a modulo,  wo  produce,  at  least  conceptually,  a < opy 
everything  it  contains.  Thus  all  the  functions  of  the  module  and  all  ' • int-  n.  b 
structures  are  duplicated  according  to  a rule  supplied  bv  the  module  itself 
implementation  terms,  copying  a function  generally  does  nothing  mot e than  u; 
the  address  of  that  function;  that  is,  because  the  < >de  is  usually  nut  m-  1 fn- 
implementation  permits  the  textual  body  of  the  function  to  lie  -h  i 
conceptually,  each  instance  provides  a distinct  copy  of  the  fum  tii  a text 
trivial  example  is  the  internal  data  structure’  of  a module,  wl.  ch  fiog  •• 
physically  copied  for  each  instance  of  1 1’ o n idule’r.  ibsfrai  tie-- 
'stack*  module  is  Instantiated,  a separate  t p-of-stack  pointer  and  Si  - 
am created  Distinct  stacks  naturally  have  distinct  top-of  t.uk  p 
however,  that  copying  of  data  in  a language  that  permits  indirect  refer  -m  • s 
called  ref  inodes)  may  simply  imply  that  distinct  instances  have  - tr  ' c - • ' 

a single  shared  structure.  I hat  is,  sharing  arises  from  copying 
structures  rather  than  the  structures  themselves. 

Therpafler , c>f  com .n?.  spparalp  insta'  -es  are  ipdepenrrpnl  '-.c  mon*  do  not  *'■■■■ 

•n  the  others. 
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We  should  also  recognize  that  the  term  instance  may  he  applied  to  both  data 
flow  and  control  flow  When  we  instantiate  a file,  we  create  a copy  of  it  (more 
precisely,  we  instantiate  tire  module  'file')  When  we  instantiate  a function,  we 
invoke  it.  Thus  if  two  distinct  users  simultaneously  invoke  the  'file  read’  function, 
we  refer  to  them  as  having  distin  tanc<  1 < - • • ■ tion  t sense,  each 

user  is  executing  his  own  "copy"  of  the  function  Within  this  noaning  of  'instance' 
as  applied  to  control  flow,  then  i 1 i n foi  »ay  *asi  • 

sharing  of  data  instances  means:  multiple  contexts  possess  the  ability  to  a cu  - 
tin'  same  data  instance.  However,  every  separate  locus  of  control  at  every  in-  tnpt 
of  time  resides  within  precisely  one  flinch  >n  instance  (by  definition),  and  la  Mm 
sharing  of  such  instances  is  impo;  able  Ibis  p.-cubar  asymmetry  of  data  and  i entro! 
instances  will  be  explored  further  in  section  4 5. 

Alphard  has  no  specific  terminology  for  the  not'  is  of  instance  and  avocation 
Wo  note,  however,  that  sppcfic  nutation  does  exist  to  control  the  instantiation 
process  for  an  individual  form  (the  "rule"  alluded  to  above).  Within  a form,  each 
data  element  (i.e  the  internal  data  structure  of  the  form)  is  identified  as  unique  (i  e. 
private)  or  shared  When  thr  form  i mstanti  Med  pies  are  marie  of  all  unique 
data  elements,  • har*>d  elcmr  ts  <itc  cc  minon  ti  ,ii!  ii,  tan  es  of  the  form  We  note 
in  passing  that  certain  kinds  of  sharing  are  not  permitted  by  this  method,  although 
some  not  rlirec  tty  available  may  hr  derived  by  .g  ; 'opri  Me  layering  of  forms  uul  the 
use  of  rof  variables  These  !<  tails  are  n,  t r levant  tr>  chsi  u sions  of  the  exception 
mechanism,  sim  e Its  di  : , , rt!  al  • ' > tl  I l< 

structure  of  (tie  kmd  prev  isly  described.  the  Alphard  facilities  meet  that 
requirement 


V 

4.3  A Gentle  I ntroduction 

We  now  have  acquired  the  necessary  background  to  discuss  the  details  of 
the  proposed  exception  handling  mechanism  To  aid  in  the  understanding  of  the 
specifics  presented  In  subsequent  sections,  wp  provide  here  a sketch  ot  the  main 
features  of  tbo  mechanism,  with  forward  references  to  the  detailed  text. 
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^ Refer  to  figure  4.1.  We  define  two  modules,  T1  and  12,  with  the  former 

using  the  abstraction  provided  by  the  latter  That  is,  for  every  instance  of  T1, 
there  is  a distinct  instance  of  T2,  which  is  referenced  inside  the  body  of  T 1 by  the 
name  's'.  These  semantics  derive  from  the  standard  Alphard  declaration  on  line  3. 


1 modu I e T 1 

2 begm 

3 yOJTiys.  s:T2 


*4 

& 

G 

7 


function  f = 
begin 

g ( s) 

end  lc : h ( v ) 1 


8 end 

3 modu I e T2 

1 0 beg i n 

1 1 cond i t i on  c ( v : i n teaer ) 


12 

13 

14 


f unc t i on  g ( t : T2 ) 
beg  i n 

raise  c ( 1 7 ) 


end 


1G 


end 


Figure  4.1:  A Simple  Example 


Although  this  simple  example  in  no  way  illustrates  the  general  flexibility  and 
power  of  the  mechanism,  by  "walking  through"  it  we  can  acquire  a sense  of  the 
workings  of  the  mechanism.  Suppose,  then,  that  within  some  instance  of  module  T1, 
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function  T is  executing.  That  is,  some  user  has  declared  a T 1 and  is  apply  ng  'f1  to 
it.  Suppose  that  'f 1 has  invoked  function  'g',  in  module  T2  At  the  moment  that  we 
turn  our  attention  to  the  example,  ' g ' is  about  to  execute  line  Id. 

An  exceptional  co  dition  has  been  detected  by  'g'  ,he  declaration  on  line  1 1 
defines  the  condition  to  have  the  name  'o'  (details  in  section  4.4)  I ins  name  is 
made  available  to  the  users  ol  TP's  ate  O action  (eg.  it)  in  the  same  way  that  the 
names  of  the  functions  (e  g.  'g')  are  he  .statement  i n Inn  1/1  raises  the  cor  Hit  if. 
'C,  which  causes  the  user  of  the  ahspa.  tu  n to  be  notified  *’  This  means  some  code 
is  to  be  executed  to  handle  the  exceptional  onditinn.  vVe  see  ttris  cone  on  line  7, 
represented  by  'h'.  Of  course,  the  detector  i flu  exception  rr.ay  wish  to  pass 
additional  information  to  the  handler  be-  ties  th  usViK'H  i a me  such  a pa:  ameter 
is  defined  in  tier  condition  declaration  (line  1 1 ) to  he  an  integer  'v'.  Its  actual  value 
at  the  time  of  detection  (lint*  14)  is  ‘1  7\  and  it  >s  : a ismitt*  d with  the  condition 
name  to  the  handler  1 h ' (line  7),  which  we  presume  a procedure  appearing 
elsewhere  within  T 1 . 

Immediately,  a wealth  of  questions  arises,  flow  was  tire  rode  on  line  7 
determined  to  be  the  handler  lot  this  condition'  (See  section  T.6  ) Could  ottier 
handlers  be  invoked  instead  or  as  well?  (Yes  - see  sections  4.6  and  4 7.) 
What  information  does  'b'  have  avail  idle  to  it  and  what  is  its  execution 
environment?  (See  sections  4.5  and  4 8.)  How  does  'h‘  influence  the 
subsequent  behavior  of  1 cj‘  and  T?  (See  sections  4 8 and  4.9)  These 
questions,  and  others,  will  all  be  addressed  in  the1  course  jf  this  chapter. 

Returning  to  our  example,  we  have  passed  the  exception  'c'  to  the  handler 
'll',  together  with  some  parameter  i r i f < rination.  We  (usually)  vie w this  notific  atiofi  as 
a subroutine  call;  that  is,  ' cj ' is  temporarily  suspended  while  'h'  executes.  (See 
section  4 8.)  'h'  performs  whatever  recovery  actions  it  chooses  (consistent,  of 
course,  with  the  semantics  of  ' f ' and  ' c; ' 1 ) and  terminates.  Control  then  returns  to 
’y 1 immediately  after  line  14  (See  section  4 9.) 
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More  questions  arise.  Must  'h'  always  return  control  to  'g'?  (hoe  sections 
4.7  and  4.9.)  Must  'g'  always  wait  for  'h‘  to  complete?  (See  section 
4.7.)  Can  'll'  alter  the  data  or  control  flow  in  'f’7  (See  section  4 9.)  I >v. 
the  answers  to  these  questions  affected  by  sharing  TP's  abstraction  among  ■ ■ .ry 
separate  instances?  (See  sections  4.5  and  4.7.)  What  about  simultaee 
parallel  execution  of  'g'  by  more  than  one  process?  Parallel  executions  of  '*'■ 
(See  sections  4.6  and  4.11.)  Wo  see  that  there  are  a considerable  number  f 
ir  ortant  issues  to  address  in  defining  an  exception  handling  mechanism  :*  is  t 
intent  of  this  example  to  raise  these  issues;  It  is  the  task  of  subset,.!!*'  t s<  1 1 ■ e 
to  handle  them 


4.4  Conditions 

W 'tat  is  a condition?  That  question  has  a philosophical  comp  *n  ' ' 

have  already  examined  (see  section  1 1).  In  this  section  we  rc  • 

• ,i  hmicntat  aspects  of  defining  conditions  within  a chosen  piug-amm  • i 


4.4  1 Condition  (\iames 

We  declare  conditions  in  much  the  same  way  that  we  declare 
t-  i 'urine  elements.  In  Alphard  we  might  write 

• ) t ion  no  space- 1 eft 

thereby  defining  an  exception.  Such  a declaration  would  <■'  i ■ *r  u 
" - oificntions"  portion  of  an  Alphard  form,  which  contains  m! 

exported  to  the  form's  users.  (In  later  sections  of  this  chapter,  we  wi. 
declaration  to  include  additional  information  necessary  for  proper  handlim  of 
exceptions.) 

Conflicts  between  condition  names  in  a particular  form  anti  nene  • 
other  forms  are  handled  in  the  same  way  that  function  name  conflicts  >< 
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Where  ambiguity  can  arise,  the  language  must  provide  a "qualifying"  notation  to 
permit  the  user  (programmer)  to  specify  the  intended  interpretation  of  a symbol. 
The  concept  of  name  qualification  to  remove  ambiguity  is  well  understood  and  not 
really  relevant  to  the  definition  of  an  exception  mechanism  Suffice  it  to  observe 
that  whatever  technique  is  used  elsewhere  in  a language  to  resolve  conflicts  witi 
serve  for  condition  names  as  well 


4.4.2  Parameters 

frequently,  a handler  requires  men  inform  ib.-n  about  a condition  than  simply 
its  name.  The  signaller  may  wish  to  transmit  addihr  i al  information  to  a handler,  and 
may  do  so  by  means  of  parameter s associated  with  the  condition.  In  this  reoard.  tire 
specification  of  a condition  appears  rather  similar  to  that  of  a function:  in  Alphatd 
we  might  write 

cond  i t i on  illegal  jir:  • • (i  ad  c o - I : s t r i nq ) 

This  notation  indicates  that  a handler  for  condition  'illegal-syml  iT  may  expect  a 
single  parameter  (of  type  'string'1’),  wh-  h (presumably)  is  relevant  to  the  handling 
of  the  condition.  As  we  shall  si  n later,  a handler  may  he  viewed  as  a subroutine 
that  is  invoked  when  a particular  condition  is  r.i  ed.  Thus  >» i r use  of  function-like 
notation  to  describe  parameter  lists  is  deliberately  sn.igestive 

4.4.3  Conditions  and  Instances 

When  an  exception  is  raised  by  a function  within  a particular  module,  the  user 
of  the  module  must  know  whether  the  exception  refers  to  a condition  that  now 
exists  within  the  module's  internal  structure  or  applies  only  to  the  function 
invocation  itself.  The  distinction  is  most  important  when  multiple  users  share  the 
same  abstraction  (module).  As  an  example,  consider  a module  that  implements  a file 
abstraction  The  'file-write'  function  specifies  two  conditions  (among  others)  that  it 
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When  we  define  an  exception  in  Alphard,  we  do  not  explicitly  specify  its  class 
as  a structure  or  flow  condition.^  Instead,  we  name  the  instance(s)  on  which  the 
condition  may  be  raised  i or  example,  the  'file-write'  function  sDove  might  begin 

func t i on  f i I e-wr i t e ( f : f i I e ) 

raises  f i I e- i neons i stent  on  f 
raises  f i I e-read-onl y on  file- write 


This  notation  indicates  that  'file-inconsistent'  s raised  on  a structural  entity  (a  tde) 
and  is  therefore  a structure  class  condition  while  file-read-only'  is  raised  on  a 
function  instance  (file-write)  and  is  therefore  a flow  class  condition  If  more  than 
one  file  might  be  subject  to  the  'file-inconsistent1  condition,  we  might  write 

func  t i on  f i I e-compare  I f , nt t le) 

r a i ses  f i I e- i nr  is i ? t * n t on  f.g 


The  raises  clause  is  always  a*  ate  with  .1  fir  1 >n  spe<  fn  at  m and  is  naturally 
exported  to  Ihe  users  of  the  t in  tion  (at  1 rally,  to  the  users  ut  the  form),  the 
condition  declaration  often  app»  irs  Nsuie  tin  function  declaration  and  groups 
information  about  the  condition  (e  <1  •?,  me  •.meter  list)  in  a single  price  this  is 
convenient  when  the  same  roud'tion  may  l r a-  u 1 v more  than  one  function  w'thin 
a form.  Additional  illustrations  may  he  found  in  tic  examples  of  chapter  < . 


4.5  Handler  Definition 

We  now  introduce  the  concept  of  n handler  for  a condition.  In  section  4.1  we 
presented  an  informal  view  of  the  actions  performed  hy  a handler,  here,  we  discuss 
the  particulars  of  handler  definition  and  relate  them  to  Alphard. 


3 w<*  stress  that  these  tenn-.  an*  tor  desrriptive  r m p-  ses  only.  They  a-  e not  necessary  loi  'he  <a.etul  definition 
0f  the  exception  mechanism,  but  a’e  introduce  1 only  tor  convenience  ir  d scussing  its  properties  and  Us 
implementation. 
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To  discuss  a handler  by  itself  is  impossible;  we  must  relate  it  to  ‘.he  condition 
it  purports  to  process  and  the  surrounding  program  text.  In  Alphard,  we  might  write 

S CC:  H] 

where  'S'  is  a program  element  (e  g.  a statement  or  block),  'C'  is  a condition  name, 
and  ' H 1 is  a handler.  We  say  that  H is  a handler  for  condition  C that  is  ass-’o  ntcd 
with  S.  It  is  important  to  stress  that  S might  he  a function  invocation,  a stati  rent 
involving  several  operations,  or  an  entire  block  complete  with  local  declarations.  In 
short,  S may  be  any  executable  program  unit  from  a primitive  operation  (f  'ion 
invocation)  up  to  and  including  an  entire  function  body.  (Under  certain  important 
circumstances,  S may  be  an  entire  module  body,  but  more  on  this  later.)  We  shou 
also  note  that  H is  treated  as  a part  ot  S tor  the  purposes  of  identifier  rusolut. 
that  is,  in  principle  H has  access  to  all  symbols  tuxes  ible  inside  S Our  notati1 
not  ideal  in  this  regard,  since  H does  not  appear  in  the  correct  lexical  nos  t ion  for 
such  access  to  occur  as  a result  of  the  normal  scope  rules. 

We  impose  some  restrictions  on  the  general  form  of  H first,  it  nrus*  not 
contain  language  constructs  that  might  irrevokably  transfer  control  utside 
lexical  scope.  This  restriction  derives  from  the  semantics  we  will  require  ;t  handler- 
termination  time  and  will  he  discussed  ,n  section  4.9.  Of  course,  H may  perform 
function  invocations,  but  it  may  not  "permanently"  transfer  control  outside  'ts 
lexical  boundaries  10  H also  may  not  attempt  to  return  from  the  functi  ' (if  tny)  > 
which  it  and  S reside.  Second,  H is  further  restricted  to  simplify  the  test  ot 
verification,  as  will  fie  discussed  in  chapter  6 However,  these  restrictions  w I 
not  materially  constrain  the  nature  of  the  computations  H may  perform,  only  'he 
syntactic  form  they  may  assume. 

We  recall  from  our  previous  discussion  (section  4 4.3)  that  conditions  and 
instances  are  closely  allied.  A condition  is  not  raised  in  t/a<  r/o,  but  relative  a 
specific  instance  A notation  that  emphasizes  this  important  point  is 

5 U.C:  HJ 
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tern  we  are  explicitly  relating  the  handler  II  te  a condition  C raised  on  instance  I 
tlor  the  duration  of  S).  We  say  that  H is  attached  to  instance  !.  Although  we  will 
frequently  omit  I when  it  is  uns  r.b  yu  r ly  tleten  ned  by  the  local  context,  its 
onoeptual  importance  cannot  he  o ‘ -stated 

I in1  full  justifif  at"  n I tai  ittachmenl  will 

norm*  in  sections  4 6 and  4 T ' ■f.  • ai  nve  a preview  here.  When  a 

, , ■ • nr  • ii. 4 it i n or  ours  (i-  • ' >tify  all  contexts  that  ini* 'nt 

p.  • . • . in  that  con  e < r a mdit'on  relative  to  an  instance. 

• \*.  i d t know  all  • n t . ar, Piers  attached  tor  the  given 

• m.  tin  parti  ijiar  -.i.v  on  h i • as  ra  sed  We  will  claim  that  this 
. • t - f - -n  tains  as  a sub*..-t  t' t > e-  her  that  should  actually  be  invoked. 

it  il  that  we  be  omh  rt  n'  with  the  notion  of  attaching  handlers  to 
instam  *>s  lot's  consider  some  examples. 

( eturning  to  the  file  example  of  sect  4 ■ wr  may  write  the  tjtiasi-Alphard 
statement 


f i I e-hir  i te  ( account  s)  [file-read-only:  h] 

Since  'filo-rend-only'  is  a 'flow'  class  condition,  d refers  tc  ■ \ itrol  instances 
(function  calls)  Thus  in  this  case,  handler  ' h ' for  condition  'file  - read-only'  is 
attached  to  an  instance  of  fun  t ■ gu  write  At  the  came  time,  'h'  is  associated 
with  the  program  frogmen4  ’fill  w ‘ (accounts)'  thus  the  evident  intern  of  this 
statement  is  to  invoke  the  ‘file  wnte’  function,  and  if  it  raises  the  'file-read-only' 
condition,  to  handle  it  hy  the  code  body  'h'.  The  instance  on  which  'file-read-only' 
is  raised  is  the  in vor  ation  of  'file  write'  a control  instance 

Now  consirler  data  instances.  Suppose  we  wiite 

file  uritef.  K counts)  [file  in  insistent:  h] 

Since  file-inconsistent  is  a 'structure'  class  condition,  we  are  attaching  'Is'  to  a 
structural  instance  (a  data  structure),  presumably  'accounts'.  To  avoid  any 
confusion  we  could  use  the  ambiguity- re*  Mution  convention  of  Alphard  and  write 
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f i I e - ur  i t e ( acc oun  tel  [accounts,  file  inconsistent:  hi 

Here,  the  program  context  with  which  the  handler  is  associated  is  identical  to  that 
of  the  preceding  example  - an  invocation  of  'file-write'  However,  the  condition 
'file-inconsistent'  is  a structural  one,  so  the  instance  to  which  'h'  is  attached  is  not 
the  invocation  of  'file-write'  but  'accounts',  an  instance  of  the  'file'  abstraction 

Clearly,  we  may  want  to  perform  different  actions  to  handle  the  'file- 
inconsistent'  condition  (raised  on  'accounts')  at  different  times  Were  this  not  the 
case,  we  would  simply  attach  the  handler  'h'  to  'accounts'  for  the  entire  lifetime  of 
the  file.  Instead,  our  notation  permits  us  to  attach  h'  to  accounts  only  for  the 
duration  of  some  context,  in  this  example,  a sin j.e  function  call  We  can  identify 
two  notions  of  "lifetime"  here  the  lifetime  of  the  instance  to  which  the  handler  is 
attached,  and  the  lifetime  of  the  c.  ntpxt  with  which  it  is  associated.  Tor  the  'file- 
read-only'  example  above,  the  two  lifetimes  were  identical;  for  the  'file- 
inconsistent'  example,  the  latter  was  contained  in  the  former  (i.e.  accounts’ 
existed  before  and  after  the  execution  ot  'file- write').  Conventional  exception 
handling  mechanisms  have  q-  neratfy  recognized  only  one  of  those  lifetimes  as 
important  (usually  the  latter),  our  me.  na  m explicitly  permits  variability  in  both 
dimensions. 

Consider  another  exami  lo  In  the  Alphard  program  fragment 


beg  i n 

private  *: integer 
file -read (old,*) ; 
file  ur  i t ( rcu  , v 4 1 ) ; 
f ■*  ur  te'1  i * no , * ) ; 

, j [r  m-i.  ‘ - n tent:  hi  I file  read-only:  h21 

we  assume  that  the  set  nd  pai  t t<  ■ to  'file  r»  ad'  is  a vat  and  the  second 
parameter  to  'fill  wnte'  i a i no  ’ 1 Iho  intent  of  the  program  fragment  is  to  read 
a value  'x'  from  file  'old',  write  'x*1*  to  file  'new',  and  write  'x'  to  file  'transaction'. 


1 1 


A vnr  • amctef  ma , t o it'p'pri  by  raV.pp 
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Note  that,  since  'file-re  id-only'  is  a H v 'a-  condition  raised  t>y  file-write,  It 

could  conceivably  be  raised  at  two  de.tn  ct  i nits  m tire  e cut  ion  of  this  program 

unit  I Inis  tlu>re  will  bo  two  instances  lilt  write  to  winch  'h2'  might  apt'!/.  We 
interpret  the  above  notation  as  a si  nth.  1 t*  ,«t  ittar  lies  a separate  copy  of  'h P' 
to  each  relevant  instance  inside  the  program  unit  wit!  which  the  handler  is 
associated. 1 The  situation  with  'filo-incem  stent'  is  rather  different.  Inis  is  a 
structure  class  condition,  and  handier  'I  1 is  idently  to  hr  used  only  if  the 
condition  is  raised  on  file  'new',  d ' onsistent1  w raised  on  either  'olii'  or 

'transaction',  this  context  would  prove'e  no  handler  to  process  the  condition. 
Depending  on  the  larger  context  n v hi  ■>  ti  fragment  appears,  such  e situation 

might  constitute  a programming  ovt  r qtd  nr  a : ' -mate,  tf » 'it  rate  strut  ‘lire 

Observe  the  relationships  that  c > st  I *t  . ■ s o.  Co  xt  and  instance  lifetimes, 
b 1 is  a 1 1 ached  to  'new.f  ■ ’ ly  f th  i tion  f t 1 pr  iram  unit, 

which  tently  a suhint  • I f • ' ' st,  'filr  vrite. file- 

read-only'  has  h?  attached  for  its  entire  lifetime,  m fact,  the  natation  suggests  that 
lip  spans  several  lifetimes  (separate  instant, es)  I et  us  examine  this  lifetime 
matter  a little  more  < arefully  and  at  the  same  time  return  to  the  question  of  handler 
placement  in  the  source  program  text 

f or  flow  • • • • irly  impos;  ble  1 changi  handlers  during  ttie 

lifetime  of  the  instance  to  winch  they  are  alt  . e-d  A control  instance  is  nothing 
more  than  a function  invo  ation,  win.  h is  i r mu!  we  oper  at  ion  from  the  viewpoint  of 
(In'  context  that  performs  it  Vet  a d da  n .<  e>  r>  • a tincture  that  normally  exists 
across  primitive  operations  1 oiiseqtiently . a pr  gram  n ly  wish  to  vary  the  handler 
action  for  a structure  class  condition  a 1 raiding  I the  context  of  execution  at  the 
moment  the  condition  is  raised  In  | art  r,  air  example  ab  we  shows  that  if  ‘file- 

inconsistent 1 is  r.ii  .'-d  on  the  tile  'new'  m th«  liven  program  context,  handler  'hi'  Is 

to  be  used  Other  contexts  that  manipi.'ate  'new'  may  supply  other  handlers. 
Specific  .illy,  we  may  want  to  hat’  do  < endi"  ns  over  the  entire  lifetime  of  a data 

nr  t nice,  just  a we  do  (by  ‘ turn)  fc  inti  ' ns  'am  es  If  that  lifot'ino  falls 

r omph  tely  within  the  exeegt  an  lib  time  of  a function  body,  then  nur  mechanism 
already  provides  a means  of  act  cmnioclnf iny  such  handlers,  e.g. 

’•  i ho  is  a , «.pli  ,il  r<.  1 1 . I i,  ’.  a i . ' o • ' -i  v.  ''  ■'  ,vp  be  body  of  h."  mthpr  man 
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pr i vate  t empf i I e: f i I e 
end  [tempf i le. f i le- i neons i stent:  hi 

However,  if  a structure's  lifetime  exceeds  a single  function  body's  oxnui’n  1 
lifetime,  this  method  is  inadequate.  Such  structures  are  of  necessity  de<  lared  i" 
the  "outer  block"  of  a module.13  For  consistency,  we  allow  a handler  to  be 
associated  with  an  entire  module  body,  thereby  attaching  it  to  an  instance  for  t e 
module's  entire  lifetime,14  e.g. 


form  account 
beg  i n 

pr i vate  acc t : f i I e ; 
end  tacct . f i I e- i neons ; steo t t h] 

All  of  our  preceding  comments  about  symbols  accessible  within  h ***’■'  > 1 

form  'h'  must  assume  still  apply.  Obviously,  it  makes  no  sense  to  attempt  t d" 
at  the  module-body  level  a handler  for  a flow  class  condition.  ’ inly  ». 

structures  con  persist  across  function  invocations 

A final  comment  about  module-body  level  handlers,  the  t "d'bm*  / rule 
below)  will  require  that,  within  a module  that  references  an  instance,  there  alwa, 
exist  at  least  one  attached  handler  for  every  condition  that  can  he  raised  r<  •'  < 
to  that  instance.  We  enforce  this  requirement  by  assuming  that,  if  no  t m 


13  For  otherwise  they  would  be  declared  e ' r and  exist  y for  the  durat 

that  function 


Strictly  for  the  lifetime  of  the  refe»ence  to  the  instance.  Alternatively,  vve  m-pht 

to  the  handier  body  with  the  declaration  . » the  .r.  'an  e,  t>  e-eby  eeipfas.nng  that  the  ha-d'er  ,s  at 
dmation  ot  that  dec  aration's  relevance 


ate  cl  < e 

h h ? . * h ^ 


15  p m cept  in  the  sence  of  the  shotthand  notation  pievmuUy  e>plairied  We  allow  such  han  l - s a' 
body  level  tor  that  iea«.on  alone 
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exists  for  a given  condition  and  instance,  the  programmer  intended  to  write  one  with 
a null  body  (i.e.  a handler  that  does  nothing)  at  t tie  module-body  level.  It  will  be 
>»  convenient  to  make  the  same  assumption  when  verifying  the  module  (see  chapter 

6). 

4.6  Handler  Eligibility 

When  a condition  is  raised,  we  may  wish  to  invoke  more  than  one  handler  to 
process  it  Hie  choice  of  handlers  to  lie  invoked  occurs  in  two  stages:  a set  of 
eligible  handlers  is  determined,  then  a subset  of  the  eligible  handlers  determined 
by  a selection  policy  is  chosen.  This  subset  will  then  receive  the  opportunity  to 
process  the  condition.  In  section  4.7  1 we  discuss  lection  policies;  this  section 
is  devoted  to  the  notion  of  eligibility.  We  first  approach  the  subject  informally,  then 
proceed  with  more  precise  definitions. 

Roughly  speaking,  we  define  a handler  II  to  lie  eligible  to  handle  condition  C on 
instance  I if  it  is  associated  with  a program  context  that  is  able  to  access  I.  By 
'ac  ' ess1  we  mean  the  ability  to  nnm.  the  instance  I.  Tor  flow  class  conditions,  this 
definition  is  essentially  trivial,  since  the  only  context  that  can  'access'  a function 
invocation  (control  instance)  is  its  caller.1^'  Thus  for  flow  class  conditions,  there 
can  be  at  most  one  context  in  which  an  eligible  handler  may  be  found. 

Structure  class  conditions  are  not  ns  simple  Because  of  sharing,  a single 
data  structure  may  be  referenced  by  several  contexts.  In  most  cases  we  have  no 
a priori  basis  on  which  to  distinguish  these  contexts,  and  we  treat  them  all  as 
eligible,  (this  statement  will  he  qualified  shortly.)  This  implies  that  a context  may 
be  considered  eligible  even  though  it  did  not  invoke  the  function  that  raised  the 
condition.  Furthermore,  if  the  system  permits  parallel  execution,  that  context  may 
be  performing  some  other  function  at  the  instant  that  the  condition  is  raised.  We 
will  examine  the  synchronization  details  in  section  4.11;  for  now  we  need  only  be 
aware  that  multifile  handlers  may  be  eligible  to  receive  the  same  (structural) 
condition. 

^ M . rA  pr  a '<-Aty,  II  a ir,Oanc.A  ol  the  tr, . • r,g  f,  I mi 
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We  observe  that  multiple  eligible  handlers  may  exist  even  if  the  programming 
system  does  not  permit  parallel  execution.  Suppose,  for  example,  that  we  have  two 
modules,  A and  B,  that  use  a single  storage  allocation  module,  ^ Assume  that  S 
provides  an  abstraction  called  a 'storage  pool’,  which  is  shared  by  all  of  its  users 
(in  particular,  A and  B).  Assume  further  that  S defines  a structure  class  condition, 
'pool-low',  that  is  raised  whenever  its  argument  pool  has  inadequate  free  space  to 
satisfy  the  requested  allocation.  Since  we  assume  no  parallel  execution  is 
possible,  only  one  module  can  invoke  'allocate'  at  a time.  Suppose  A does.  If 
'allocate'  raises  'pool-low',  should  we  a priori  deny  B the  opportunity  to  handle  the 
condition  and  free  some  space0  Certainly  not  A and  B share  the  storage  pool 
provided  by  S,  arid  our  mechanism  should  and  will  consider  both  modules  eligible  to 
handle  conditions  raised  by  S Sharing,  not  parallelism,  produces  multiple  eligibility. 

lot  us  now  proceed  to  the  details  of  eligibility  determination.  Since  flow  and 
structure  class  renditions  may  be  treated  analogously,  we  will  focus  our  attention 
on  the  latter  class,  since  the  absence  of  sharing  of  control  instances  makes  the 
former  class  less  interesting. 


4.6.1  The  Eligibility  Rule 

In  order  to  give  a precise  definition  of  eligibility,  we  must  introduce  some 
terminology,  first,  we  need  to  tighten  up  our  meaning  of  "context".  Consider  an 
executable  program  unit,  that  is,  a well-formed  piece  of  source  code  that  forms  a 
subpart  of  a function  body  (perhaps  the  entire  body).  If,  at  a given  instant,  that 
code  is  being  executed,  then  an  instance  of  the  function  body  must  exist.  Indeed, 
a operate  instance  will  exist  for  each  distinct  execution  of  the  function, 
regardless  of  whether  such  executions  are  serial  or  parallel.  Within  each  instance, 
there  will  be  an  instant  at  which  our  chosen  program  unit  is  entered  and  another  at 
which  it  is  exited  Between  these  two  instants,  the  program  unit  is  said  to  be 
ri<  ti ire  (with  respect  to  the  given  function  instance).  In  a parallel  system,  the  same 
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program  unit  may  be  active  in  many  different  function  instances  at  once. 

We  next  restrict  our  attention  to  active  program  units  that  are  relevant  to  a 
particular  condition  and  instance. 

Del  Suppose  that  condition  C has  been  raised  on  instance  I. 
Consider  all  active  program  units  that  have  an  associated 
handler  for  condition  C attached  to  instance  I.  (Of  course,  some 
of  these  will  be  properly  nested,  but  we'll  deal  with  that  in  a 
minute.)  We  call  this  set  of  active  program  units  the  contexts  in 
which  C raised  on  I can  lie  handled  We  will  say  that  a handler 
is  enabled  if  either  (1)  it  is  associated  w th  (an  instance  ot ) a 
module  body  in  which  I is  referenced  (named),  or  (2)  it  is 
associated  with  a context  in  which  C can  be  raised  on  I (For 
reasons  indicated  at  the  end  of  section  d.fS,  we  always  consider 
modulo-body  level  handlers  to  be  enabled.) 


We  need  one  additional  preliminary  definition. 

Def.  Suppose  HI  and  HP  are  distinct  enabled  handlers  and  81  and  S2 
are  respectively  the  program  units  with  which  they  are 
associated  We  say  that  HI  masks  HP  if  either  (1)  S2  is  a 
module  body  within  which  SI  is  lexically  nested  or  (2)  neither  SI 
nor  S2  is  a module  body,  but  SI  is  lexically  nested  in  S2  and  the 
contexts  associated  with  HI  and  HP  are  subparts  of  the  same 


^ ^ s»  h,1ve  C .V  efl  illy  fl  . -t*»d  1 1 *.  3 1 1 *»  V’lrp  ' (If  n • " | o , s e *.f  OUI  linwilll  ng'  >e  SS  to  ,1  H'Q'I  ll  3 specific 
meaning  in  this  discussion.  "Prr  e*'"  Ms  i n rn.iny  implementahr  ’ specific  connotation*  However.  wo  note 
informally  that  (barring  recursion)  s ■-  Ma' **  j sly  ocr ' g tan  es  of  the  .ame  funclion  t'elcng  to  separate 
processes.  In  the  subseq  e n t para  raphs  we  will  c s t at' 1 1 sh  doLn.trons  Rial,  wthout  resorting  to  Ibe  dohnitron  of 
"process",  pinpoint  within  each  pr<  ress  that  lete'e-  .-  es  a data  instance  the  contents  in  which  the  signalled 
condition  should  be  bar. died 
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An  enabled  handler  H is  said  to  be  meshed 


if  there  exists  some  other  enabled  handler  G such  that  G masks 


We  can  give  a piecise  definition  of  eligibility 


Del . A handler  is  eligible  (to  process  a condition  on  a given  instance) 

If  it  is  enabled  and  not  masked 

to  see  what  this  means  more  concretely,  wi  will  extend  an  earlier  exami  1 - 'r 

storage  allocator  S and  its  u ?rs  A let  'usea'  and  'useb'  be  t in  t.  ns  ' 

modules  A and  B,  respectively  Sketch  s of  these  modules,  written  in  p' 

y ("t 

Alphard,  appear  in  figures  4 p and  4 3.'  J Allocate'  is  assumed  to  i“  1 t 
assign  a ’block1  of  ' i ' storage  units  fiom  the  specified  pool  ' p ‘ . If  it  ccirmot  1 so,  it 

p i 

raises  'pool-low'  on  p'  and,  after  all  e igible  andlers  have  comp  c-ted.  trie-  n 
If  the  • ' ^ The  'release'  function  a; 

to  raise  any  exceptional  conditions 

First,  let  iis  assume  that  no  parallelism  is  permitted.  (The  two  modules 
coded  are  prepared  to  handle  potential  par  ili>  lism,  which  wo  discuss  in  the  n <.  t 


' A nearly  equivalent,  and  perhaps  s rjnt'y  m 'e  »r> • ■ ^ . r .r.  way  to  state  (2)  is  neither  St  nor  c-.  is  .• 

body,  both  SI  and  S2  belong  to  the  »ame  m du  e and  S'  •«.  c.  tmirally  nested  v:th»n  S 2 L ■f  rt  »te  r « 

def  nitron  appeals  imptir  • t •* y to  *’  e r ' * es'"  i a «n  • explicates  ve  fica»  on 


A word  of  caution  is  in  #der  these  example '»  a ••  »w^at  s.mplif  od  The  df-  rat  ••ns  * v ^ 1 1 r- 
tR  am  intended  to  denote  the  sarr.*  i tyre,  a * n igh  m strict  Alphard  they  w ’ »ld  dftn  *«  d.ffe  » * '•  Vo  i e 

also  or*  1 1 »*  g certain  deled s about  hander  ter ant  ■ t a have  not  yet  been  e »p  a *d  <*e  s*  or 
better  still,  ignore  the  details  for  ow 

4 1 Again,  we  ignore  untit  so  t on  4.7  the  r **  t -an  srr  that  ma^e^  this  possb  e 


‘ Or-  e agam,  we  must  • npi  fy  for  iili  • batr  ' p r;  es  No<rna',,  allocate’  would  r«*sf»  a so  >d  ’ 

here  eg  'pr  I #»  i • f y ‘ , thi  •"  y pe  • | r.  i • ***■.*.  i \ . r « * < r-  --me  t e % for  ’nil'  To  f 

this  point  and  because  we  would  otherwise  have  t i'e«vme  mate'  al  from  «.ertior  4 9,  we  • h -so  the 

traditional  expedient  of  an  • r V H r value  1 • denote  * e-  .ept  on 
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form  A ■= 
beg  ija 

shared  p:pool 
private  k. , I : ha  i r u I i s t 
f one  t i on  usea ( i : in  t ) - 

beg  i n 

pr i va t e r : b I ock 

z*-a  I I ocate  (p,  i ) 

i f r = ni  I tb»n  return  fi 

< fill  in  ' z ’ > 

en  t pr  I I , z I 

end  [pool- low:  sgumere  1 1 ) ] 
end  [poo  I - I ow : ( so . ;ee re  ( I ) ; r 'in <=>=.■  e | k I ) ] 


Note:  ‘ squeeze ' it  • • . f orjn  ‘t  • . * t ' . 


Figure  4 ? A Simple  Use  of  the  'Pool'  Abstract  on 

paragraph  Thu  "no- parallelism"  aeumption  merely  causes  the  handler  on  line  P9  to 
be  superfluous  ) Suppose  that  'pool-low'  is  raised  ns  a result  of  the  call  to  'allocate' 
on  line  8 By  our  assumption,  the  only  func  tion  instance  from  which  'p'  can  be 
accessed  is  'uses'  Conse  piei  t the  enabled  handlers  are  those  on  lines  12,  13, 
and  31.  However,  by  c lause  (1)  of  the  definition  >f  masking  (above),  the  handler  on 
line  IP  masks  the  one  on  line  13.  Thus  the  eligible  handlers  ate  on  lines  12  and  31. 
If,  however,  'pool-low'  wore  raised  by  the  call  on  line  23,  the  enabled  handlers 
would  be  on  lines  13,  23,  30,  and  31  By  clause  ( 1 ) of  the  definition  of  masking, 
line  30  masks  line  31.  by  clause  (P),  Ime  P3  masks  line  30.  Thus  in  this  case  the 
eligible  handlers  would  he  on  lines  13  and  23. 

A more  interesting  situation  arises  when  we  allow  parallelism.  Suppose  two 
processes  iodepend  aitly  invoke1  'usea'  and  'nseh'  Specif u ally,  at  the1  instant  that 
process  1 calls  'usea',  process  2 is  executing  line  28  in  'usob'.  If  'pool-low'  is 
raised  ns  a result  of  'usea'  e ailing  'allocate',  the  enabled  handlers  will  he  those  on 
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Figure  4.3:  A More  Involved  Use  of  the  'Pool'  Abstraction 

lines  12,  30,  and  31,  and  hence  the  eligible  handlers  will  be  on  lines  12  and  30. 
Note  that,  since  'useb'  is  being  executed  concurrently  at  the  instant  'pool-low1  is 
raised,  the  handler  on  line  30  masks  the  one  on  line  31.  Consider  what  happens  if 
process  2 has  just  passed  the  begin  on  line  29  at  the  instant  'pool-low'  is  raised. 
Now  line  29  contains  an  enabled  handler  as  well,  and  by  clause  (?)  of  the  definition 
it  masks  line  30,  leaving  1?  and  29  as  the  eligible  handlers.  The  purpose  of  coding 
a null  handler  body  on  line  29  is  to  take  advantage  of  the  masking  to  disable 
temporarily  the  unwanted  behavior  of  line  30.  The  full  power  of  this  masking  effect 
cannot  be  appreciated  until  we  have  discussed  handler  semantics  in  sections 
4.8  and  4.9.  We  will  return  fo  this  example  in  chapter  7. 


form  B = 
beg  i n 

shared  p : poo  I 
pr i va  te  m , n : ha i r y I ist 
f unc  t i on  useb  ( i : i ri  t ) = 
beg  in 

private  zl,z2: block 
zl*-al  I ocate (p,  i ) 
i f zl  -ni  I then  return  f i 

z2«-a  I I oc  a te  (p , i +3)  [poo  I - I ow:  r e I ease  (zl ) : z]  *-n  i I ) 
i f zl =n i I 

t hen  r r 1 1 ir  n 

ej  - e if  zZ^nil  then  release(zl);  return  f_i_ 
f i 

< fill  in  ‘zl ’ and  ‘z."  > 

beg i n enter  (m, zl ) ; enter  (m,z2)  end  [pool-low:  1 

end  [poo  I- low:  squeeze  (nil 

end  [pool-low:  ( squeeze (m I ; squeeze(n))) 
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4.6.2  Another  View  of  'Contexts' 

Because  the  notion  of  eligibility  rests  at  the  heart  of  our  exception  handling 
mechanism,  we  must  have  a clear  picture  of  its  purpose.  The  definitions  of  the 
previous  section  identify  for  us  the  contexts  that  will  be  considered  eligible  to 
process  a given  condition  raised  on  a given  instance.  Perhaps  by  recasting  these 
definitions  in  operating  system  terms  we  can  reinforce  the  intended  ideas.  We  will 
use  the  terminology  of  Hvdra  os  defined  in  [Cohen  75] 

A context,  in  Hydra,  is  an  object.  Objects  are  used  to  group  capabilities  for 
related  objects  We  may  view  an  object  in  which  a particular  capability  resides  as 
defining  the  environment  (i.e  the  capabilities)  needed  when  the  given  capability  is 
manipulated  in  a specific  way.  Stated  slightly  differently,  the  object  defines  a (not 
necessarily  unique)  usage  environment  with  respect  to  the  particular  capability.  (Of 
course,  the  object  serves  this  same  purpose  for  each  of  the  capabilities  it 
contains.) 

For  a specific  instance  I (which  is  an  object),  we  may  consider  the  set  S of 
objects  that  contain  a capability  for  I.  Assuming  that  every  object  in  S contains  a 
body  of  code  to  handle  an  exception  C raised  on  I.  we  can  say  that  S is  the  set  of 
contexts  in  which  C (raised  on  I)  can  be  handled/’3  This  corresponds  to  the 
definition  of  "context"  in  the  preceding  section 

At  a given  instant,  S may  contain  objects  of  type  INS  (that  is,  objects 
corresponding  to  function  activations).  Indeed,  for  flow  class  conditions  (i.e. 
conditions  raised  on  I when  I is  itself  an  I NS),  S has  precisely  one  member,  which  is 
of  type  I NS.  We  make  no  special  provisions  regarding  l NSs  or  non-LNSs  - a 
context  may  be  an  object  of  arbitrary  type.  This  is  in  basic  contrast  with  either 
f>xr  option  handling  mechanisms. 


.Strictly  speaking,  we  should  limit  S to  thn  set  o!  bjn  Is  that  contain  a capability  lor  I but  do  not  form  a part  ot 
the  protected  subsystem  that  implements  tbe  type  I which  1 belongs.  We  clearly  do  not  want  to  include  Ibe 

implementing  module  (envirr  riment)  am  eg  the  ",  .ig"  -t  i ns  (envn onments) 
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1 ho  eligible  handlers  set  is  determined  (at  a given  instant)  by  identifying 
within  each  member  of  S the  body  of  code  that  is  prepared  to  handle  condition  C. 
Clearly,  for  each  context,  the  eligible  handler  may  change  with  time.  The  eligibility 
rule  given  in  the  preceding  section  selects  a single  eligible  handler  from  the  enabled 
handlers  within  a single  context  (in  S)  It  does  so  by  the  usual  lexical  scope  rules. 
However,  we  should  realize  that  the  fundamental  principle,  for  the  purposes  of  our 
mechanism,  is  the  determination  of  the  set  8 Within  each  context  in  S,  the  policy 
used  to  determine  the  eligible  handler  (at  a given  instant)  is  of  secondary  interest. 
T1  ere  are  really  two  levels  of  selection  here  the  environments  (contexts, 
protection  domains)  that  use  I,  and  the  code  bodies  within  these  environments  that 
will  actually  process  C The  first  level  is  * ntiai  to  our  mechanism,  the  second  is 
not.  Within  the  latter  we  have  chosen  Ihe  onvt  ntional  scope  rules  for  familiarity 
and  convenience,  but  the  same  cx  option  transmission  principle  could  easily  be 
applied  to  another  choice  It  is  important  to  ret  ionize  these  distinct  levels,  even 
though  they  do  not  appear  - xplicit  > in  the  (rather  1 rgeneous " ) definitions  of 
the  previous  section. 


4.7  Raising  Conditions 

We  now  turn  our  attent  on  to  the  semantics  at  the  sile  where  a condition  is 
raised.  We  w ant  to  est,  : nsh  what  control  the  signaller  has  over  the  invocation  of 
handlers  and  what  the  si  in ailer  is  entitled  to  assume  after  such  invocation,  let  us 
examine  those  issues  in  turn 


4.7.1  Selection  Policies 

By  definition,  a condition  ran  only  be  raised  within  the  module  in  which  it  is 
defined  (i.e  in  whir  h the  r.  mdition  declaration  appears).  In  Alphard  we  might  raise 
'fill  -inconsistent'  by  the  ex-  ■<  utahle  statement 


i ... 
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Wn  assume  that  the  declaration  of  this  condition  (see  section  4 4.3)  appears  in  the 
specifications  part  of  a form,  i.e.  the  part  of  the  module  that  describes  the 
abstraction  to  its  user.  The  raise  statement  above  would  appear  in  one  or  more  of 
the  functions  of  the  same  form.  For  example,  consider  the  following  skeleton 
function: 

bodg  file-urite(f:file) 
beg  i n 

ij^  not  cons  i s t en  t ( f ) 

t hen  raise  file  i neons  i e t ent  f j_; 

end 

'Consistent'  is  a predicate  that  tests  the  concrete  representation  of  a file  to 
determine  if  it  is  indeed  consistent.  Again,  we  assume  that  the  above  code  appears 
within  form  'file'. 

Now  let  us  consider  the  choice  of  handlers  to  he  invoked  In  preceding 
sections  we  defined  the  notion  of  eligibility  but  suggested  that  it  might  not  always 
be  desirable  to  invoke  all  eligible  handlers  when  a condition  is  raised.  We  establish 
the  principle  that  an  eligible  handler  should  be  invoked  only  when  tire  condition  for 
which  it  is  eligible  exists  At  first  glance  this  st  ems  a vacuous  statement,  but  a 
simple  example  will  demonstrate  otherwise.  Consider  the  'pool-low'  condition  in  the 
example  of  the  previous  section.  In  general,  more  than  one  eligible  handler  exists 
for  this  condition.  Suppose  that  'pool-low'  is  raised.  It  must  be  that  insufficient 
storage  exists  in  the  (shared)  pool  ' p * to  satisfy  some  allocation  reguest.  Assume 
for  the  moment  that  the  (eligible)  handlers  are  invoked  one-at-a-time  in  an 
unspecified  order.  It  is  quite  possible  that  the  first  handler  will  release  adequate 
storage  to  satisfy  the  pending  request  Why,  then,  invoke  the  remaining  handlers? 
In  actuality,  the  'pool-low'  condition  has  ceased  to  exist  after  termination  of  the 
first  handler,  and  thus  by  the  above  principle,  we  should  not  invoke  another  eligible 
handler,  even  though  many  more  may  exist. 

this  example  in  addition  illustrates  a particular  selection  policy.  This  policy 
would  cause  handlers  to  he  successively  invoked  as  long  as  the  given  condition 


/ 3 


THE  MECHANISM 


CH  A 


persists.  We  will  specify  the  , ret  se  semantics  of  this  policy  shortly;  first, 
however,  we  observe  that  other  reasonable  policies  exist.  For  example,  c insider 
the  1 ollowinr } variant  of  the  ‘pool  nrlit  e 1 »t  tl 

when  a request  could  not  be  •■■it  sf  • to  i v<  is  storage 

possible  within  th«  leed,  it  might  wi  to  d ; sc  is  the  a 

space  dropped  below  a certain  threshold,  nt  necessarily  when  « request  could  not 
be  honored.  Such  a condition,  say  'pool-under  threshold',  might  be  broad  ast  to  ail 
eligible  handlers;  by  definition,  'pool-und.  < threshold'  would  he  said  to  persist  ti  im 
the  detection  of  the  threstv  j until  alt  eligible  handlers  have  c< 

execution. 

Another  facet  of  selection  policies  is  tin*  degree  of  i aralleMsm  they  permit 
among  the  eligible  handlers  and  the  signaller  Must  the  signaller  wait  for  all 
selected  handlers  to  terminate?  Do  the  rs  execute 

in  parallel'7  The  answers  to  these  important  questions  signifu  antly  infli  i*nre  the 
structure  of  the  handlers  and  the  sigt  alter,  a • well  a;  th£  prt  cise  s<  int  s 
condition.  We  could  easily  define  a large  number  of  policies  by  arying  the  sol  set 
of  eligible  handlers  selected  and  the  extent  of  parallel  p*  ><  ssmq  ng  - * 
Indeed,  we  naturally  ask  hew  w<  can  i ha r ac i • i i.o  the  space  of  s elec  t mo  i ie *, 

The  principles  of  modu  ar  decompo:  md 

formulate  properties  that  selection  policies  should  have.  From  these  properties  we 
will  seek  on  i|  ( rpriatr  ...  n our  * 

ha ndling  mechanism. 

4.7.1 .1  Properties  tor  Selection  Policies 

Because  handlers  appear,  hy  ch  finition.  in  mob  iles  other  than  tiro  signalling 
cne,  tlu*  ' ignaller  bos  no  knowledge  of  their  individual  actions.  It  thus  makes  little 
sense  to  provide  a mechanism  that  permits  explicit  selection  bom  the  set  of  eligible 
handlers  I ho  signaller  has  no  a piiori  knowledge  about  handlers;  it  cannot, 
Ihorefore.  determine  in  advance  those  that  should  lie  invoked,  lor  the  same 
reason,  the  signaller  cannot  specify  the  order  n whic  h selected  handlers  are  t : o 
invoked  Hence  a necessary  property  of  an  ac  ceptable  selection  policy  is  that  it 
cannot  postulate  the  existence  of  a priori  information  that  distinguishes  individual 
eligible  handlers. 
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Even  in  the  absence  of  handler-specific  information,  we  can  still  formulate 
policies  that  require  only  a subset  of  the  eligible  handlers  to  be  invoked.  Such 
policies  rely  on  the  state  of  the  signaller  before  handler  selection.  An  example  of 
such  a policy  is  that  described  above  for  the  'pool-low'  condition,  which  uses  the 
state  of  the  storage  pool  to  determine  if  additional  handlers  should  be  invoked.  A 
consequence  of  the  "anonymous  handler"  property,  therefore,  is  that  a (proper) 
subset  of  the  eligible  handlers  may  be  chosen  by  the  selection  policy,  but  the 
determination  of  that  subset  must  follow  solely  from  information  available  within  the 
signalling  module. 

The  second  property  a selection  policy  should  possess  affirms  the  "principle 
of  condition  persistence",  mentioned  above,  that  is,  the  selection  policy  should  not 
permit  a handler  to  be  invoked  when  the  condition  for  which  it  is  eiiti  hie  does  not 
exist.  Frequently,  the  selection  policy  may  come  close  to  violating  this  property,  as 
for  the  'pool-low'  condition  above.  'Tool-low1  and  'pool-under-threshold'  differ  only 
slightly,  hut  the  selection  policies  and  subsequent  behavior  of  the  signaller  differ 
substantially  in  the  two  cases  In  fact,  we  might  view  the  semantics  of  'pool-under- 
threshold' to  have  been  derived  from  those  for  'pool-low'  in  such  a way  as  to 
satisfy  the  dictates  of  the  "con  ! ti persistence"  principle. 

A cotollary  of  this  principle  1 1 at  all  handlers  selected  by  a policy  most  have 

been  (at  least)  invoked  taefore  e xi  tir'd  of  the  raise  statement  completes.  If  this 
were  not  so,  then  a handler  mild  hr  iked  when  no  raise  on  its  condition  is  in 
progress  - a direct  violation  of  "condition  persistence".^  ^ 

The  final  property  a sele<  lion  policy  must  exhibit  is  perhaps  less  obvious  than 
the  preceding  two.  We  require  that  the  policy  he  associated  with  the  condition,  not 
with  an  occurrence  of  n raise  statement  naming  that  condition  Thus  all  raise 
statements  for  a condition  will  necessarily  use  the  same  selection  policy.  The 
reader  may  find  this  restriction  difficult  to  accept,  since  it  seems  plausible  that 
diftiuent  selection  policies  might  he  useful  under  different  circumstances. 
Experience  suggests,  however,  that  such  situations,  if  they  arise  at  all,  really 
involve  two  subtly  different  conditions  (eg.  'pool-under-threshold'  and  'pool-low'). 
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furthermore,  in  such  cases  handlei  a tion  is  generally  slightly  different  under  the 
two  policies.  I his  would  imply  providing  the  handler  with  the  knowledge  of  which 
policy  was  in  force  at  its  invocation.  Such  know'' ■■dun  would  violate  the  pm  ipl  « of 
information  hiding,'  1 and  would  complicate  verification.  It  is  not  impossible  to 
construct  verification  conditions  in  Hv  absence  of  this  restriction,  but,  unless  the 
policies  are  very  similar,  the  proofs  are  likely  to  he  ome  much  mute  difficult. 

4.7. 1.2  Specific  Selection  Policies 

With  those  properties  in  mind,  let  us  define  some  selection  policies.  We  do 
not  claim  to  exhaust  the  space  of  acceptable  policies,  hut  those  defined  here  will 
he  adequate  to  illu -trate  the  intent  of  the  above  rules.  We  anticipate  that  an 
implementation  of  our  premised  mechanism  would  supply  (some  of)  thr-u  policies 
and  perhaps  ■ if  her  s,  I :t  ■ .mid  m t necessarily  si.  ply  a set  of  primitives  that  permit 
the  definition  of  n.  w of'S/'"  We  will  identify  each  policy  by  a keyword  for 
convenient  future  roferen  e 

Our  I - t v ••  a i d / ro.idi  ast-ancf-ivarf  Linder  this  policy,  all  eligible 

handler  ■ are  . ■ _.  ...  I e .iiel  ' ' When  all  handlers  thus  initiated  have  < mpleled, 
execution  fMin'r  immed.at  elv  following  the*  raise  statement  Thus  while  all 
eligible  handlers  execute  (conceptually,  at  least)  in  parallel,  the  signaller  is 
suspended  until  they  complete 

An  obvious  variation  ot  this  policy,  simply  called  broadcast,  relaxes  the 

r,.r,<  P selection  p ilicies  are  !>  und  nly  1 e ' U the  ina  .;  ■ 

, . . , | )f)  fy  }t  • • ' ■ • V)  ' tO  V • 

invocation. 
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completion  requirement.  All  eligible  handlers  are  initiated  in  parallel,  but  the 
signaller  does  not  wait  tor  any  ot  them  to  complete  It  merely  continues  executing 
following  the  raise  statement.  Thus  all  handlers  and  the  signaller  execute  in 
parallel. 

The  last  policy  we  will  define  here  is  sequential-conditional.  (This  policy  was 
used  implicitly  in  the  'storage  pool’  examplp  above.)  Associated  with  the  raise 
statement  is  a predicate.  The  predicate  is  evaluated  and,  if  true,  execution 
continues  following  the  raise  statement.  If  the  predicate  is  false,  an  eligible 
handler  is  selected  and  initiated  When  it  completes,  the  predicate  is  again 
evaluated.  (We  insure  that  each  time  a different  handler  is  selected.)  The  raise 
statement  terminal  rs  when  either  the  predicate  becomes  true  or  the  set  of  eligible 
handlers  is  exhausted. c ® 

We  close  this  discussion  ot  selection  policies  by  relating  them  lo  condition 
classes.  Since  the  class  (structure  or  flow)  of  a condition  determines  the  set  of 
eligible  handlers,  the  effect  of  the  selection  policy,  which  chooses  from  that  set, 
obviously  depends  on  the  condition  class  We  note  that  the  above  policies  are 
applicable  to  either  class,  although  for  the  'flow'  class  certain  degeneracies  occur. 
Since  there  can  be  at  most  one  eligible  handler  for  a 'flow'  class  condition, 
broadcast-and-wait  and  sequential-conditional  are  (in  practice)  equivalent. 

This  'special-case'  nature  of  flow  class  conditions  reveals  an  important 
aspect  of  selection  policies:  the'*  are  generally  interesting  for  structural  conditions 
only.  Ttie  possibility  of  multiple  eligible  handlers  arises  from  shared  (data) 
instances;  it  is  for  shared  structures  that  this  exception  handling  mechanism  has 
been  designed.  Some  previous  mechanisms  try  to  operate  in  environments  in  which 
(by  definition)  only  one  eligible  handier  exists,  and  such  degenerate  handler  sets 
are  demonstrably  inadequate  for  shared  data  structures. 


' ^ (t  might  Re  sefijl  lo  .slier  th  ,s  alq^rillvm  sl.qhtly  In  fear  lire,  a vs  use  ess  to  test  the  pred  ate  Perove  ^-electing 
\hf  first  handler,  '.incp  a t » pr  ed'  tip  v.  >uld  r 'P  the  raise  statement  to  do  noth  top  However,  »t  s useful  to 
know  aflef  the  rn  that  the  v **d'c  alp  is  fa'sp  if  and  only  if  all  piiq-ble  handlers  have  bonn  invoked  Altering  the 
algorithm  to  test  after  invorah  ~ prevents  tn  v^r.  It  a’^o  affec ts  ver-f-  ahon  * see  section  6 d 2 
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4.7.2  Tho  Raise  Statement 

In  terms  of  control  flow  semantics,  the  ' i • statement  acts  much  like  a 
function  call.  Although  the  signaller  does  not  know  how  many  handlers  will  be 
invoked,  it  does  know  that,  at  some  point,'  control  will  return  to  the  statement 
immediately  following  the  raise.  The  signnTer  ki  ows  that  control  may  leave  its 
module  for  some  period  of  time  but  nothin'!  any  handler  can  do  (short  of  looping 
indefinitely)  can  prevent  control  from  returning  t cp  se-  tior  4.9.)  The  moment 
of  return  is  determined  by  the  selection  policy 

For  an  ordinary  function  r til,  tin?  • u • • entitled  to  assume  a certain 

predicate  holds  after  the  function  is  cunipadi  t that  predicate  is  specified  by  the 
implementor  of  the  abstraction,  namely,  1 1 1 » m a ••  m winch  the  function  i1-  defined. 

When  raising  exceptions,  the  situation  run  tin  cre  the  signaller  is  entitled  to 

assume  that  a certain  predicate  holds  <j  >nr  Ibe  raise  statement  has  been 

executed  Once  ogam  the  predicate  i sci  : > d by  the  implementor  of  the 

abstraction,  but  in  this  case,  the  impiemi  at  >;  • f no  ■ ■ ik  ' od rile  that  contains  the 

raise,  by  definition  Bec  ause  tire  signalling  module  sui  plies  the  predicate,  it 
compels  the  handlers  to  make  that  predicate  true  We  w i i I examine  the 
consequences  of  this  form  of  semantic  specification  in  chapter  6. 

It  is  important  to  note  that  few.  if  any,  ot 1 1 • excel  lion  handling  mechanisms 

require  control  to  return  to  1 1 ■ « signall"'  upon  h.i  all  r • a •>  .nation  Some  permit  it, 

but  do  not  enf  r • 1 es)  to  process 

an  unusual  condition  that  cannot  be  handle  i eu’  inly  ,vr  am  the  ■ 'unalling  module, 
they  have  an  obligation,  • i re?  • i by  the  prerl  itr  tin  jna  h r,  and  the 
signaller  will  a ,ume,  upon  conipletion  of  ' rusi  that  the  obligation  has  been 
satisfied.  If  handlers  wore  able  to  t*  rn  , e pi  ematni  ely  the  execution  of  the 
signaller,  the  abstractions  of  the  signall  lg  moduli  |ht  not  b<  maintained.  The 
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signalling  and  handling  modules  should  be  viewed  as  mutually  suspicious  subsystems 
[Schroeder  72];  neither  should  be  able  to  influence  adversely  the  execution 
of  the  other,  for  this  reason,  our  exception  mechanism  requires  that  handlers 
return  control  to  the  signaller,  from  the  signaller's  point  of  view,  a handler  is 
nothing  more  than  an  unnamed  function. 

A final  detail  concerning  the  raise  statement  should  be  mentioned.  It  may  be 
necessary  to  indicate  on  what  instance  the  condition  is  being  raised.  If,  for 
example,  there  is  a function  'compare-file'  that  compares  t fie  contents  of  two  files 
passed  as  parameters,  it  will  be  necessary  to  specify  which  of  the  two  parameters 
is  intended  if  'file-inconsistent'  must  be  raised.  We  might  write 

ra i se  f i I e - 1 . f i I e - i neons i s t en  t 

to  avoid  ambiguity.  Such  qualifications  are  necessary  only  when  a function 
manipulates  two  or  more  (data)  instances  of  the  same  'type'  during  a single  call.  Nio 
problem  can  arise  in  specification  of  flow  class  conditions,  since  the  current 
executing  function  instance  is  the  only  possible  relevant  one. 

4.8  Handler  I ni/ocation  Semantics 

We  come  at  last  to  the  semantics  of  the  handlers.  We  can  view  the  task  of  a 
handler  as  consisting  of  two  parts:  performing  recovery  actions  on  behalf  of  the 
signaller,  and  altering  the  local  context  at  t tie  handler  site  to  reflect  the 
occurrence  of  the  condition.  (Tor  any  particular  condition,  either  of  these  actions 
may  be  null.)  Thus  a handler  requires  information  from  the  signaller,  which  it 
receives  through  the  condition  name  and  parameters  (see  section  4 4),  and  from  the 
associated  program  context,  which  it  receivers  by  the  normal  scope  rules  of  the 
language. 

Recall  from  section  4 C>  that  an  eligible  handler  always  lias  an  associated 
program  unit,  which  may  be  executing  at  the  instant  the  handler  is  invoked.  If  so, 
we  require  that  the  execution  of  that  program  unit  be  suspended  until  the  handler 
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terminates.  That  is.  the  handler  inter/ upts  its  associated  program  context  when 
selected  for  execution;  it  does  not  run  asynchronously.  This  is  n crucial  distinction 
in  light  of  the  handler's  responsibility  to  alter  local  context  to  reflect  its  recovery 
actions.  If  the  handler  executed  asynchronously  with  its  associated  context, 
complicated  and  costly  synchronization  would  he  needed  to  prevent  undesirable 
interference  in  the  manipulation  of  local  data. 

It  is  important  to  understand  that  the  associated  context  is  interrupted 
immediately.  Fven  though  the  context  may  be  performing  some  function  whose 
implementation  exists  outside  the  scope  of  the  current  module,  interruption  is 
immediate  and  causes  that  function's  execution  to  bo  suspended  Failure  to  do  so 

a t 

con  result  in  a deadlock.  We  can  restate  the  rule  in  a less  formal,  though  perhaps 
more  intuitive  way  hy  saying  that  the  "process"  in  which  the  program  context  is 
executing  is  interrupted,  and  the  handler  then  executes  within  that  process  with 
access  to  the  local  variables  of  the  context  with  which  it  is  associated.  I he 
handle!  does  not  have  access  to  the  variables  of  the  immediately  interrupted 
context  unless  it  is,  by  coincidence,  the  context  with  which  the  handler  is 
associated.  (Recall,  however,  that  we  prefer  to  avoid  definitions  that  rely  on  the 
notion  of  "process",  since  the  embedding  language  may  not  provide  any  such 
concept  at  the  user  level.) 

We  observe  that  reliance  upon  processes  leads  to  difficulties  when  we 
consider  handlers  that  are  assocaated  with  entire  module  bodies.  Recall  from 
section  4.0  that  such  handlers  are  eligible  only  when  no  function  within  the  module 
body  has  the  condition  enabled  (relative,  of  course,  to  some  particular  instance).  In 
informal  terms,  there  is  no  activity  within  that  instance  - the  data  structure  is  not 
being  manipulated.  We  cannot  necessarily  identify  a "process"  that  should  be 
interrupted  in  order  to  invoke  the  eligible  handler,  yet  that  in  no  way  should  prevent 
its  execution.  I ho  data  to  which  the  handler  should  have  access  is  well-defined  by 
its  lexical  placement,  the  "control  environment"  is  unspecified.  Probably  the 


1 ' ler,  for  example,  the  situation  in  which  the  only  eligible  handler  is  ass  >.  «ated  with  the  content  that 

invoked  the  fun-  tion  that  raised  the  co  ndition.  If  we  wa  \ to  invoke  the  hand'©*  until  control  return*  to  its  level  of 
.rt  * ' a ? on  (i  e the  level  at  wh*ch  its  associated  pm  j a*n  context  executes),  we  have  a deadlock,  a'ssummg  tt>e 
h >n  policy  involves  wading  for  t .«  idler  completion 
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implementation  will  have  to  find  a "null"  process  in  which  to  execute  the  handler, 
but  at  the  level  of  functional  behavior  this  detail  does  not  concern  or  interest  us. 
Wo  merely  specify  the  context  in  which  the  handler  must  execute  ind  allow  the 
implementation  to  realize  that  specification  any  way  it  chooses 


4.9  Handler  Termination  Semantics 

to  complete  our  exposition  of  the  exception  handling  mechanism  we  examine 
the  semantics  that  apply  when  a handler  c vnpletes  Its  execution.  There  are  two 
obvious  aspects  to  consider:  the  effect  on  the  signaller  and  the  effect  on  the 
interrupted  context. 

Under  some  selection  policies,  the  signaller  is  unable  to  continue  execution 
until  the  handlers  have  completed.  The  signaller  will  need  to  assume,  in  most  such 
casc»s,  that  it  is  impossible  for  its  execution  to  be  aborted,  for  the  abstraction  it 
maintains  is  very  likely  to  be  in  an  inconsistent  state  at  the  instant  a condition  is 
raised.  As  intimated  in  the  preceding  section,  we  require  that  a handler  be 
incapable  of  preventing  the  resumption  of  its  signaller.  This  is  in  sharp  contrast  to 
most  existing  exception  handling  mechanisms,  which  either  permit  or  prescribe 
termination  of  the  signaller.  This  abortion  of  the  signaller  may  be  satisfactory  for 
certain  conditions,  but  is  inadequate  for  situations  in  which  the  signaller  wishes  to 
act  upon  the  results  of  the  handler  (e.g  a storage  allocator  that,  after  raising  'pool- 
low1,  wants  to  determine  if  it  now  has  adequate  resources  to  satisfy  a pending 
request).  We  reject  It  as  a general  rule.  Under  the  proposed  mechanism,  the 

O P 

signaller's  execution  always  continues  immediately  following  the  raise  statement. 

Although  a handler  cannot  alter  the  flow  of  control  in  its  signaller,  it  can 
change  the  local  flow  of  control  within  its  associated  context.  This  means  that  the 
handler  c.an  cause  control  to  resume  at  a point  other  than  the  point  of  interruption. 
The  precise  nature  of  the  control  flow  change’s  permitted  is,  of  course,  language- 
dependent,  but  for  the  purposes  of  this  section,  we  assume  only  that  the  handler 
has  the  option  of  causing  control  to  leave  the  associated  context.  (In  effect,  this 
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gives  us  a kind  of  "local  abort".)  We  recall,  however,  that  the  handler  may  not 
transfer  control  outside  its  own  scope  (see  section  4.5).  The  actual  transfer  of 
control  occurs  ncd  when  the  handler  terminates,  but  when  control  returns  to  its 
associated  context  at  the  point  of  interruption.  Stated  another  way:  the  handler, 
upon  completion,  "posts"  the  location  at  which  execution  of  its  associated  context 
is  to  resume.  Normally  (and  by  default),  the  posted  location  is  the  point  of 
interruption,  but  if  the  handler  so  specifies,  it  may  be  the  textual  end  of  the 
program  unit.  The  transfer  to  the  posted  location  occurs  when  control  returns  to 
the  interrupted  context. 


f unc t i on  useb ( i : i n t ) - 

I : beg  i n 

private  rl,z2:block 
r 1 *-  a I I o c a t e ( p , i ) 
t z 1 = n i | then  return  f i 

z2*-a  I I ocat e (p,  i +3)  [poo  I - I ow:  r e I r a?e  ( rl ) -*  l eave  I ] 
< fill  in  ‘ z 1 ’ and  1 z2 ' > 

beyLn  enter  (in,  zl ) ; enterlm.zZ)  end  tpool-lou:  ) 

end  [pool -low:  squeeze (m) ] 

Figure  4 4 Improved  Version  of  'useb' 


Wo  can  see  the  utility  of  local  alteration  of  control  flow  for  conditions  that 
represent  the  permanent  failure  of  some  action  Returning  to  our  allocator  example 
again,  we  can  see  the  convenience  of  being  able  to  leave  the  body  of  function 
'useb'  (see  figure  4.3)  when  'pool-low'  is  raised  as  a result  of  the  call  to  'allocate' 
on  line  ^3  Wo  could  then  eliminate  much  of  the  troublesome  checking  for  'nil'  that 
clutters  the  main-line  code  Fxtending  the  notation  of  section  4.5,  we  might  write 

S 1C:  H - T) 
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where  T specifies  the  change  of  control  flow  that  is  to  be  posted  when  H 
terminates. ^ We  could  then  recode  'used'  as  shown  in  figure  4 4.^ 


4.10  An  I nformal  Recapitulation 

In  this  chapter  we  have  expounded  the  details  of  a proposed  exceptional 
condition  handling  mechanism.  Recause  of  our  stated  intention  to  do  so  outside  thr 
confines  of  a particular  language's  syntax  and  semantics,  the  presentation  may 
have  seemed  vague  and  the  factual  detail  elusive  Chapters  5 to  8 
attempt  to  justify  the  definitions  of  this  chapter  by  re-examining  them  in  the  light  of 
the  goals  stated  in  chapter  1.  For  convenient  reference  and  to  help  the  reader 
understand  the  motivation  for  the  elaborate  definitions  of  this  chapter,  we  restate 
here  the  important  notions  embodied  in  the  proposed  mechanism 

’ The  exception  mechanism  presumes  an  embedding  language  that 
explicitly  supports  the  principle  of  information  hiding,  which 
separates  knowledge  of  functional  behavior  (abstraction)  from 
internal  workings  (representation  or  implementation) 

* Conditions  are  defined  by  the  implementor  of  an  abstraction,  and 
their  names  and  abstract  meanings  are  made  available  with  the 
names  and  abstract  meanings  of  the  functions  provided  by  a 
module. 

* Handlers  are  executable  program  units  (normally  procedures) 
supplied  by  the  user  of  an  abstraction  to  process  exceptions 
(conditions). 

* Tire  notion  that  binds  handlers  to  conditions  is  the  instance.  Only 
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Note  that  this  improved  version  could  still  he  ; ' ed  by  addition  of  other  conditions,  as  observed  m section 
/I  6. 
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those  contexts  that  use  a particular  instance  can  supply  handlers 
for  the  conditions  that  may  arise  on  the  instance.  Put  slightly 
differently:  the  implementor  of  an  abstraction  detects  and  raises 
conditions  on  its  instances,  the  users  of  the  instances  supply  the 
handlers  to  respond  to  those  conditions. 

Notions  like  "process"  and  "call-stack"  are  se  ondary, 
implements*,  n-spec.ific  concepts  that  do  not  figure  directly  in 
the  transmission  of  exceptional  conditions.  We  phrase  our 
definitions  and  organize  our  thinking  with  the  view  that  there 
exist  instances  of  abstractions  and  users  of  those  instances. 
That  dependency  relation  is  foremost;  relations  tike  "A  calls  B" 
are  secondary. 

Conditions  are  ci-  ‘ ned  to  apply  to  either  control  instances 
(function  invocations)  or  data  instances  (data  structures).  This 
'class'  of  the  condition  dett  rminos  what  is  meant  hy  a 'user'  of 
the  instance  on  which  the  < midition  is  raised. 

When  a condition  is  raised,  two  criteria  determine  the  handlers 
that  will  be  invoked  to  process  it  the  eligibility  rule  and  the 
selection  policy.  The  eligibility  rule  defines  the  contexts  within 
modules  using  the  instance  that  will  he  considered  eligible  to 
have  their  associated  handlers  invoked.  The  selection  policy 
defines  the  subset  of  the  eligible  handlers  that  will  actually  be 
invoked. 

Since  the  eligibility  rule  allows  tor  dynamic  changes  in  control 
flow,  the  set  of  eligible  handlers  for  a given  condition  and 
instance  varies  with  the  state'  of  the  modules  supplying  the 
handlers  (the  us'  rs)  Tin  'election  policy  permits  dynamic  state 
changes  in  the  implementation  of  the  instance  (resulting  from 
handler  execution)  to  affect  the  actual  invocation  of  handlers. 
Thus  both  user  and  implementor  can  influence  the  exception 
handling  process,  hut  only  in  well-defined  ways. 
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>>  * Handlers  cannot  alter  the  flow  of  control  within  the  signaller,  but 

they  are  able  to  force  local  branching  within  their  associated 
contexts.  Functions  that  raise  conditions  may  therefore  assume 
that  their  execution  cannot  be  terminated  by  external  means. 
Local  changes  in  control  flow  initiated  by  handle- s actually 
simplify  the  structure  of  their  associated  contexts  by  eliminating 
the  need  for  explicit  polling  for  exceptions. 


4.7  7 A Postscri pt:  Synchronization  Esoterica 

Wo  have  presented  the  details  of  the  exception  handling  mechanism  without 
paying  particular  attention  to  questions  of  synchronization,  even  though  at  several 
points  wo  stated  that  certain  program  units  would  execute  in  parallel.  Two 
synchronization  issues  arise:  one  pertains  to  synchronization  within  the  exception 
handling  mechanism  itself,  the  other  involves  the  interaction  between  the  exception 
mechanism  and  the  synchronization  facilities  of  the  embedding  language.  We  will 
consider  the  former  here;  we  postpone  the  latter  until  chapter  5 Because  the 
material  of  this  section  is  relevant  only  to  implementation,  it  has  been  separated 
from  the  discussion  of  the  functional  behavior  of  the  exception  mechanism. 

The  first  observation  about  synchronization  behavior  applies  to  maintenance  of 
the  eligible  handler  set  for  a given  instance  and  condition.  This  set  is  defined  at 
the  moment  ttiat  the  condition  is  raised  on  the  instance,  but  the  implementation  will 
maintain  it  over  time  so  that  it  is  available  at  the  instant  the  condition  is  raised. 
The  definitions  require  that  the  eligible  handlers  set  remain  unchanged  while  the 
raise  statement  is  being  executed,  but  since  the  set  is  determined  by  the 
instantaneous  control  points  of  asynchronously  executing  processes,  it  is  Fable  to 
change  at  any  moment.  It  is  necessary,  therefore,  to  prevent  interfering  changes 
by  ensuring  certain  mutual  exclusion.  Specifically,  any  attempt  to  alter  or  examine 
an  eligible  handlers  set  must  he  performed  in  a critical  section  protected  by  a 
mutual-exclusion  semaphore  (or  similar  synchronization  construct).  Such  accesses 
occur  in  three  places:  entry  to  and  exit  from  a program  unit  with  which  a handler  for 
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Uniformity 


"What's  true  ot  one  peculiar  case  is  true  of  all 
peculiar  cases  of  the  s-ime  peculiar  sort." 

- James  Thurber,  The  White  Deer 

This  chapter  evaluates  the  exception  mechanism  of  chapter  -1  with  respect  to 
the  goal  of  uniformity  enunciated  in  chapter  1.  Recall  that  "uniformity'  in  this 
co.itext  refers  to  consistent  application  of  the  mechanism  within  multiple  levels  of  a 
programming  system.  We  can  approach  the  question  in  two  ways  (1)  by 
demonstrating  that  the  facilities  provided  by  the  mechanism  work  effectively 
throughout  a system,  and  (2)  by  showing  that  the  mechanism  is  largely  independent 
of  language-specific  semantics.  From  the  former  we  conclude  that  the  mechanism 
is  indeed  useful  for  exception  handling  problems  that  arise  at  many  system  levels-, 
from  the  latter  we  conclude  that  the  semantics  of  the  mechanism  are  compatible 
with  languages  used  at  those  levels,  the  utility  of  the  mechanism  is  best  illustrated 
by  examples  of  'typical'  exception  handling  situations,  whose  presentation  we 
defer  until  chapter  7.  In  this  chaper  we  concentrate  on  the  relationship  of  the 
exception  mechanism  to  other  language  concepts  that  may  affect  the  exception 
handling  process 


5.7  / nteractions  with  the  Embedding  Language 

We  want  to  show  that  our  mechanism  is  largely  independent  of  other  si 
constructs  in  its  embedding  language.  By  doing  so  we  will  establish  the  ft 
of  implementing  a single  set  of  semantics  for  exception  handling  " 
programming  system.  (Chapter  7 will  demonstrate  that  those  s. 
indeed  useful.)  We  will  examine  a number  of  language  concepts  t it 
exception  handling  and  consider  how  the  mechanism  responds  i . 

in  their  semantics. 
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5.1.1  Variable  Access  and  Scope  Rules 

The  permissible  forms  of  access  to  data  strongly  influence  the  expressive 
power  of  a language.  As  a direct  consequence,  they  materially  affect  verifiability. 
Naturally,  languages  used  at  different  system  levels  and  with  different  verification 
requirements  will  specify  different  access  rules.  Our  mechanism  should  not 
interfere  with  that  language  prerogative. 

The  primary  interaction  of  scope  rules  and  the  exception  mechanism  occurs  in 
the  handler  bodies.  A handler  requires  information  from  two  sources  the  signaller 
that  invokes  it  and  the  program  context  with  which  it  is  associated.  In  order  to 
avoid  the  use  of  shared  global  variables,  the  mechanism  permits  a signaller  to  pass 
parameters  to  handlers.  Of  course,  if  the  embedding  language  permits  shared  global 
variables,  the  exception  mechanism  in  no  way  hampers  their  use.  However, 
verifiability  may  be  compromised  or  complicated  in  such  languages,  hence  the 
mechanism  supplies  a controlled,  explicit  transmission  facility  for  languages  that 
prohibit  implicit,  unrestrained  communication  through  global  variables.  The 
parameters  are  not  constrained  by  the  mechanism  to  be  value-only,  though  for  some 
selection  policies  (eg.  broadcast)  var  parameters  have  little  utility.  Generally, 
handlers  for  structural  conditions  communicate  results  to  the  signaller  by  function 
invocations  (see,  e g.,  section  7.4.1),  and  handlers  for  flow  conditions  return 
results  through  var  parameters  (see,  e g.,  section  7.3).  Of  course,  the  precise 
method  of  communication  is  determined  by  the  specifications  of  the  module  that 
defines  the  condition,  and  it  may  mix  the  two  techniques  freely.^ 

The  interaction  of  the  handler  and  its  associated  program  context  is  less 
explicit.  The  mechanism  stipulates  only  that  the  handler  has  (implicit)  access  to  the 
same  data  that  its  associated  context  has  At  first  glance,  this  might  seem  to 
require  complex  manipulations  to  ensure  such  access.  However,  the  cost  is 


Handlers  do  not  have  ’return  values',  la'ge'y  be;  ause  .1  r*’  a^e’**rs  a<  comphsh  the  same  result,  allow  muJtipl® 
return  values  conveniently,  require  no  additional  syntax  <n  either  s-goaMpr  or  handier,  a'e  equivalent  tn  verification 
difficulty,  and  allow  certain  desirable  'def a1  jHmp'  (see  se-  hen  7 ?.  2) 
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dependent  upon  the  nature  of  the  normal  case  access  control.  In  BLISS,  lor 
example,  language  restrictions  on  accessing  eliminate  the  need  for  an  AlGOL-like 
display  mechanism.  The  entire  accessing  context  of  a handler  can  be  (is) 
represented  by  a single  pointer;  loading  that  pointer  into  a particular  register  gives 
the  handler  access  to  the  required  data  in  a single  instruction.  The  same  is  true  for 
BLISS  subroutine  entry.  In  full  ALGOL-60,  however,  display  management  at  function 
entry  is  more  expensive,  and  handler  entry  follows  suit.  Since  handlers  are  treated 
(and,  in  general,  implemented)  much  like  procedures,  we  naturally  expect  the  cost 
of  establishing  the  handler  context  to  be  commensurate  with  the  cost  of 
establishing  a procedure  context.  This  permits  the  language  design  to  specify 
access  rules  without  worrying  about  complexities  that  might  be  introduced  by  the 
presence  of  the  exception  handling  mechanism. 


I 


L 


l 


5.1.2  Shared  Data 

This  section  and  the  two  that  follow  it  deal  with  closely  related  topics.  From 
earlier  comments  we  recall  that  the  exception  handling  mechanism  seeks  to 
accommodate  shared  data  structures.  The  interesting  case  occurs  when  a single 
structure  (instance)  is  accessible  from  two  or  more  contexts  that  are  not  lexically 
nested.  We  have  already  considered  examples  of  such  situations,  e g.  the  storage 
allocator  example  of  chapter  4.  If  a language  permits  this  kind  of  sharing,  then 
there  are  natural  interactions  between  the  sharing  contexts  which  raise  questions 
about  parallelism  and  its  control  (synchronization).  Thus  if  the  exception  handling 
mechanism  interacts  with  sharing  of  data,  it  must  interact  with  parallelism  and 
synchronization  as  well.  We  will  examine  these  interactions  separately,  insofar  as 
it  is  possible  to  do  so. 

A language  may  not  permit  sharing  of  the  kind  just  described,  or  it  may  provide 
a restricted  form  of  it  (e.g  Alphard  - see  section  4 2)  The  eligibility  rules  of 
section  4.6  are  intended  to  cope  with  whatever  form  of  shared  data  the  language 
permits.  However,  if  no  "interesting"  sharing'’  is  possible,  the  eligibility  rule  simply 
reduces  to  a rule  that  finds  a single  eligible  handler  for  a particular  condition  and 

2 

"Interesting  mean*,  that  multiple  non  nptlpd  rpfpfen'P'  (.an  evi*>t  simultaneously. 


91 


_ J 


UNIFORMITY 


CH.  5 


instance.  The  mechanism  in  no  way  requites  a language  to  accommodate  shared 
data,  it  merely  provides  sufficiently  yeneral  rules  to  deal  with  it 

The  principle  underlying  the  eligibility  rules  is  that  of  a user.  The  mechanism 
does  constrain  the  language  to  supply  a sufficiently  precise  definition  of  the  "user 
of  an  instance"  that  the  eligibility  determination  can  be  made.  In  chapter  4 we 
spoke  of  the  "ability  to  reference"  an  instance,  and  used  it  as  the  informal 
definition  of  "user".  We  have  also  used  the  term  "capability"  in  a similar  way.  The 
essential  requirement  is  that  one  be  able  to  determine,  in  a given  context,  what 
instances  are  accessible.  The  determination  may  be  made  partly  at  compile-time, 
partly  at  run-time,  with  efficiency  depending  on  the  degree  of  run-time  checking 
required.  languages  that  support  information  hiding  (a  requirement  for  our 
mechanism)  generally  support  strong  typing  as  well,  so  the  additional  restrictions 
imposed  by  the  exception  handling  mechanism's  definition  of  'user'  are  minimal  to 
non-existent. 


5.1.3  Parallelism 

At  several  points  in  the  discussion  of  the  exception  mechanism,  we  noted  that 
certain  operations  could  proceed  in  parallel.  (See  especially  section  4.7.1). 
Naturally,  some  languages  do  not  provide  parallel  processing,  and  those  that  do  may 
provide  it  in  one  of  several  ways.  The  exception  mechanism  never  requires  that 
actions  occur  in  parallel;  it  merely  defines  those  points  at  which  conceptually 
independent  actions  are  allowed  (if  the  language  and  implementation  permit)  to 
proceed  simultaneously.  Wherever  previous  discussions  have  used  the  words  "in 
parallel",  purely  sequential  systems  may  substitute  the  words  "in  undefined  order". 
As  w e have  already  noted,  certain  selec  tion  policies  may  collapse  into  a single  one 
in  a sequential  system. 

Although  the  mechanism  can  take  advantage  of  parallelism  if  available,  it  does 
not  define  precisely  the  way  in  which  its  actions  are  to  be  mapped  onto  the 
execution  units  provided  by  the  language.  This  has  been  done  deliberately  so  that 
several  distinct  "styles"  of  parallelism  can  be  accommodated.  For  example,  some 
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languages  may  explicitly  provide  a "process"  abstraction.  Others  may  define 
parallelism  implicitly  in  terms  of  collateral  evaluation.  Still  other  forms  ore  possible 
(e.g.  Hibbard's  'eventual'  values  in  ALGOL-68  [Hibbard  76]).  Since  the 
exception  mechanism  definition  states  only  the  possibility,  not  the  necessity,  of 
parallel  execution,  it  does  not  stipulate  how,  or  even  if,  the  parallelism  is  to  be 
achieved  by  the  embedding  language.  In  many  cases  it  is  sufficient  for  the 
programmer  to  know  that  he  must  be  prepared  for  parallel  execution;  the  means  by 
which  it  is  implemented  often  are  irrelevant  and  need  not  be  related  to  other 
language  constructs. 


5.1.4  Synchronization 

Unfortunately,  we  cannot  dismiss  synchronization  as  easily  ns  we  did  parallel 
processing.  Because  we  do  not  want  the  exception  handling  mechanism  to  specify 
that  any  particular  synchronization  facilities  he  present  in  the  embedding  language, 
we  define  its  synchronization  behavior  directly  (see  sections  4 8 and  4.11). 
Although  this  does  not  constrain  the  form  of  the  language  facilities,  it  does 
introduce  complexities  in  the  interaction  of  those  facilities  with,  the  exception 
mechanism.  Let  us  consider  two  examples. 

1 ) Suppose  a function  within  some  module  M can  raise  a condition  C 
under  a selection  policy  that  causes  the  function  to  wait  for  the 
handlers  to  complete  (e.g.  broadcast-and-wait).  If  M expects  to 
operate  in  a parallel  environment,  it  will  very  likely  provide  some 
mutual  exclusion  of  its  functions.  Vet  if  any  handler  for  C 
attempts  to  invoke  a function  of  M that  requires  mutual  exclusion, 
a deadlock  may  ensue. 

2)  Suppose  that  a module  M has  a function  F that  may  raise 
structure-class  condition  C.  Suppose  further  that,  under  normal 
circumstances  (i.e.  when  C is  not  raised),  F may  be  executed  in 
parallel  by  an  arbitrary  number  of  users.  However,  suppose  that, 
because  some  consistency  test  within  F fails,  C is  raised. 
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Presumably  the  same  test  will  fail  in  all  asynchronous  executions 
of  F that  are  manipulating  the  same  (data)  instance.  This  may 
cause  more  than  one  user  to  reacli  the  raise  statement  for  C. 
Since  the  exception  mechanism  implements  its  own  mutual 
exclusion  requirements,  only  one  user  at  a time  will  be  permitted 
to  execute  the  raise.  Nevertheless,  as  soon  as  one  completes  it, 
another  may  immediately  raise  the  same  condition  again.  This 
amounts  to  multiple  notifications  of  the  same  condition,  a 
complexity  that  the  handlers  may  not  he  able1  (or  willing)  to  cope 
with.  The  obvious  difficulty  here  is  that  the  mutual  exclusion  has 
occurred  too  late  - the  consistency  test  has  already  been 
executed.  By  enforcing  mutual  exclusion  on  the  test  (with  some 
language  construct),  we  synchronize  all  executing  instances  of  T 
(operating  on  the  same  data  instance),  but  that  unfortunately 
defeats  the  original  purpose  of  executing  such  instances  in 
parallel. 


We  could  devise  other  scenarios,  but  the  point  should  be  clear  Interactions 
between  synchronization  primitives  and  the  exception  mechanism  arc*  subtle  and 
complex.  There  are  really  two  questions  raised  by  these  examples:  does  the 
exception  mechanism  constrain  the  form  of  synchronization  primitives,  and  what 
language  construct(s)  do  we  need  in  order  to  avoid  the  pitfalls  illustrated  by  the 
examples  above?  The  latter  question  is  considered  in  section  5.2;  we  address 
the  former  here. 

Note  that  the  difficulties  that  arise  in  these  examples  stem  from  the 
interaction  of  the  exception  mechanism  with  separately  defined  mutual  exclusion 
requii  ements.  Nowhere  was  any  mention  made  of  specific  primitives  used  for  mutual 
exclusion;  it  is  the  concept  that  leads  to  the  difficulty.  Indeed,  we  could  work 
through  the  details  of  these  examples  using  semaphores  [Dijkstra  68], 
monitors  [Home  /4],  critic. al  regions  [Rrine.h  Hansen  r’2],  path 
expressions  [Campbell  { 4],  or  any  other  specific  technique  for  achieving 
mutual  exclusion,  and  we  would  arrive  at  the  same  result.  I he  problem  is  endemic 
to  the  interaction  of  the  two  mechanisms.  One  might  leap  to  the  (fortunately 
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unjustifiable)  conclusion  that  ttie  exception  mechanism  intolerably  constrains  the 
use  of  mutual  exclusion.  As  a partial  rebuttal,  figure  5.1  presents  an  (admittedly 
unattractive)  solution  for  the  second  example  above,  using  semaphores  as  the  only 
synchronization  construct.  (A  solution  to  the  first  example  appears  in  section 
7.4.1.)  We  claim  therefore  that  the  mechanism  does  not  limit  the  forms  of 
synchronization  permitted,  but  exposes  a need  for  more  sophisticated  combinations 
of  synchronization  and  exception  handling  primitives,  combinations  that  avoid  these 
pitfalls.  We  are  thus  led  to  the  second  question  posed  in  the  preceding  paragraph, 
whose  answer  is  the  subject  of  section  5.2. 


modu I e T 
beg  i n 

cond i t i on  structurnl-errnr  po'icy  hroadcas t -and -wa  i t 
private  size: integer 
pr i vate  sem: mutex 

< other  data  comprising  the  fine  structure  of  a *T'  > 

f unc t i on  length!  t:T)  returns  s:  integer 

raises  structural -error  gn  t 
beg  i n 

i f not  consi stent ( t) 
then 

Pit. sem) 

i f not  cons i s ten t ( t ) 
then 

raj_se  t . s true  fur  a I -error 
< restore  *t’  to  a consistent  state  > 
f_i_ 

V ( t . sem) 

n_ 

s «-  t . s i ze 
end 

< ...  other  functions  ...  > 
end 


Figure  5.1:  Mutual  F ' elusion  under  t xceptional  Circumstances 
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5.1.5  Protection 

The  design  presented  in  chapter  4 tias  not  incorporated  any  specific  features 
to  control  the  dissemination  of  information,  with  two  exceptions,  first,  it  respects 
the  principle  of  encapsulation,  and  therefore  permits  no  representation  information 
to  be  transmitted  via  exceptions  unless  explicitly  sent  by  the  signaller.  Second, 
the  mechanism  respects  the  principle  of  mutual  suspicion,  and  therefore  restricts 
the  flow  of  control  during  exception  handling,  these  two  principles  are  consistent 
with  the  language  properties  assumed  in  section  3.1.1.  Besides  these  properties, 
the  mechanism  is  intended  to  be  neutral  with  respect  to  protection  problems,  but  we 
can  offer  no  demonstration  that  specific  protection  problems,  e g confinement,  are 
not  complicated  by  its  presence.  It  is  guite  possible  that  covert  channels  for 
leaking  information  may  exist  in  the  exception  transmission  mechanism,  but  it  should 
also  be  noted  that  the  potential  recipients  of  an  exception  are  the  possessors  of 
capabilities  for  an  instance.  By  controlling  distribution  of  those  capabilities,  a user 
worried  about  confinement  should  be  able  to  limit  the  spread  of  information  through 
signalling  of  exceptional  conditions.^  In  general,  however,  the  mechanism  does  not 
pretend  to  address  protection  issues  other  than  encapsulation  and  (to  a limited 
extent)  mutual  suspicion. 


5.2  Simplifying  the  Use  of  the  Mechani sm 

Although  we  have  claimed  that  the  exception  handling  mechanism  does  not 
impose  significant  semantic  constraints  on  other  constructs  in  the  embedding 
language,  we  have  observed  (particularly  in  section  5.1.4))  that  interactions 
between  constructs  may  give  rise  to  ceitain  usage  paradigms.  We  may  look  upon 
such  paradigms  ns  seeking  to  smooth  over  difficulties  in  the  use  of  the  exception 
mechanism  and  other  language  elements.  Let  us  briefly  consider  the  reasons  such 
difficulties  arise. 


‘ If  a module  has  h»»en  verified,  then  its  execution  behavior  is  (almost)  completely  defined  by  its  specif  icat»ons. 
Thi*  may  further  boUter  its  user's  confidence 
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As  illustrated  in  section  5.1.4,  attempts  to  combine  use  of  synchronisation 
primitives  and  the  exception  mechanism  can  easily  produce  deadlocks  and  ottier 
undesirable  behavior.  The  example  of  figure  5.1  suggests  that  combinations  of 
primitive  functions  that  yield  correct  behavior  may  not  be  immediately  obvious  or 
inherently  pleasing.  Vet  if  seems  reasonable  to  hope  that  we  can  identify  certain 
common  situations,  such  as  those  cited  in  section  5.1.4,  and  ’higher-level" 
operations  that  directly  handle  them  After  all,  such  synchronization  "pr  r.iitiv/es"  ns 
monitors  and  conditional  critical  regions  exist  precisely  because  the/  respond 
directly  to  particular  usage  patterns.  Just  as  we  define  monitors  to  provide  on 
access  control  paradigm  connecting  synchronization  and  function  invocation,  so  we 
can  define  control  flow  paradigms  connecting  synchronization  and  exception 
handling  It  is  beyond  the  scope  of  tins  thesis  to  explore  the  space  of  specdic 
possibilities  in  detail,  but  we  can  consider  the  example  of  figure  5.1  'he  mutex 
semaphore  is  intimately  connected  to  the  testing  of  the  consistency  piedieate, 
which  in  turn  is  intimately  connected  to  the  raising  of  the  exception  it  appears 
desirable  to  bundle  this  diverse  collection  of  language  elements,  and  the  control 
structure  that  links  them,  into  a single  syntactic  unit  whose  semantics  would  be 
more  immediately  understood.  Such  a unit  might  be  implemented  by  syntax  macros 
the  method  is  unimportant  - but  it  should  at  least  be  known  to  the  implementation  in 
such  a way  that  its  increased  readability  may  be  reflected  in  a more  potent  or 
convenient  proof  rule.  We  naturally  expect  that  a more  intuitive  construct  should 
be  simpler  to  verify,  and  our  aim  in  introducing  such  paradigms  should  be  to  enhance 
both  clarity  and  verifiability. 

Paradoxically,  obr  desire  to  keep  the  exception  mechanism  verifiable  has,  in 
some  cases,  made  its  operation  /ess  nattiial  and  more  difficult  to  understand.  In 
such  situations  we  wish  to  introduce  constructs  that  combine  language  elements 
because  we  hope  to  recapture  clarity  without  sacrificing  verifiability  Perhaps  the 
most  glaring  example  is  the  notion  of  an  abnormal  function  termination.  Assuming 
that  an  abnormal  completion  (e  g.  overflow  during  floating-point  addition)  is  to  be 
reflected  through  our  exception  mechanism,  we  have  no  machinery  at  our  disposal 
but  to  raise  some  condition.  Yet,  since  raise  never  alters  control  flow  in  the 
signaller,  we  must  follow  the  raise  with  a separate  return  statement  to  achieve  the 
desired  effect.  Obviously,  we  could  define  a trivial  language  construct  that 
combines  tire  raise  and  return,  but  the  conceptual  difficulties  at  the  handler  site  are 
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less  easily  resolved.  If  we  are  raising  a flow  class  condition  (this  is  almost 
invariably  the  case  for  abnormal  termination),  the  (only  eligible)  handler  is  attached 
to  the  context  that  invoked  the  signalling  function  The  coder  will  often  prefer  to 
think  of  the  handler  body  as  performing  some  local  fix-up  actions,  followed  by  a 
transfer  of  control  (perhaps  another  abnormal  termination)  However,  the  semantics 
say  that  the  handler  termination  causes  control  to  return  to  the  signaller,  which  then 
performs  a return,  transferring  control  back  to  the  calling  context  'where  any  local 
transfer  of  control  posted  by  the  handler  then  takes  effect.  Ibis  is  unnecessarily 
cumbersome  - instead  we  introduce  an  appropriate  construct,  defined  in  terms  of 
the  primitives  just  employed,  that  looks  to  the  programmer  just  like  the  desired 
abnormal  function  termination.  Such  a usage  paradigm  .simplifies  understanding,  yet 
its  formal  definition  via  the  existing  mechanism  retains  verifiability.  In  fact,  if  such 
a construct  is  intimately  known  by  the  implementation  (as  opposed  to  a user-written 
syntax  macro),  efficiencies  in  object  code  si/e  and  execution  speed  can  be 
realized. 

We  may  summarize  the  preceding  d'scussion  by  observing  tire  need  for 
"humanely-engineered"  extensions  to  the  lac. mage  that  includes  our  exception 
handling  mechanism.  This  need  arises  In • cause  cert ain  usage  paradigms  exist  that 
combine  separate  language  elements  to  f urn  a < < >nsi-  tent,  more  intuitive  construct 
We  have  seen  examples  that  combine  either  synchronization  or  function  return  with 
exception  handlering,  and  we  could  easily  produce  others.  Only  experience  and 
further  investigation  will  determine  what  language  extensions  significantly  simplify 
the  task  of  understanding  programs  that  employ  the  proposed  exception  handling 
mechanism. 


Verifiability 


" Humph ! These  arguments  sound  very  well,  hut  I 
can't  help  thinking  that,  if  (hey  A/ere  reduced  to 
syll  ^gistic  form , they  wouldn't  hold  water." 

- W S.  Gilbert,  Ruddigore 

In  tbe  discussion  of  preceding  chapters  we  have  often  referred  ’ the 
properties  of  the  exception  handling  mechanism  as  being  influenced  by  the 
for  verifiability.  In  this  chapter  we  consider  the  problem  of  verifying  i P ’•  v 
use  the  proposed  mechanism.  Since  we  can  only  present  the  verlfi  •'»  ■ r h - n 
the  context  of  a specific  language,  we  will  rely  heavily  on  the  m >'  s ok! 
structure  of  Alphard,  our  chosen  embedding  language  (see  s^c  ! n h VI)  It 
Alphard  verification  methodology  is  well-developed,  and  since  it  i >p  in','  nt  !i 
extend  it  in  a natural  way,  we  will  first  establish  some  conventions  and  assumptions 
that,  in  effect,  embody  that  methodology  informally.  While  lev  than  ri.:or  sis,  t''is 
short-cut  permits  us  to  avoid  a rehashing  of  known  techniqu''  We  11  i c.,  fine 
predic  ntes  to  characterize  the  semantics  that  were  described  operationally  in 
chapter  d.  Using  these  predicates,  we  develop  proof  rules  for  the  signalling  and 
handling  constructs,  finally,  we  assess  the  value  of  this  approach  and  ihe  utility  r.I 
the  resulting  rules. 


6.  1 Assumptions  and  Conventions 

The  verification  methodology  of  Alpluud  utilizes  Hoaro's  axiomatic  approach 
[Monro  60],  and  we  shall  construct  our  proof  rules  accordingly.  This  formu'ation 
modeh  naturally  the  specification  of  functions  as  assuming  some  pre-credit  >n  and 
esl.ibli  .lung  some  post-condition.  Of  course,  other  verification  methods  are  likely  to 
work  as  well,  e g tlijkstra's  weakest  pre-condition  technit)ue  [Dijkstra  f6],  but 
our  presentation  will  use  Hoaro's  method. 


A • I'htrar  y . f |h»»  Alplafd  vprdra'v  rp\).  idol^-g/  app^a'S  tn  apt  ° dix  B. 
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We  insist  that  modules  he  independently  verifiable;  that  is,  to  prove  a 
particular  module  we  require  only  its  source  text  (with  assertions)  and  the 
specifications  (predicates)  that  define  the  semantics  of  the  modules  it  uses.  Our 
proof  rules  will  make  it  possible  to  verify  the  body  of  a signaller  without  consulting 
the  code  of  related  handlers,  and  to  verify  those  handlers  separately  without 
knowing  the  implementation  of  the  sigrirMer.  The  practical  application  of  verification 
to  systems  composed  of  many  modules  (as  those  using  the  exception  mechanism 
are  likely  to  be)  depends  crucially  on  this  property 

We  assume  the  existing  Alphard  rules  for  accessing  variables.  I he  details  of 
the  rules  need  not  be  presented;  it  suffices  to  understand  their  motivation.  When 
we  verify  a program,  we  need  to  be  able  to  identify  all  distinct  variables  it 
manipulates.  Both  parameter  binding  (for  procedure  calls)  and  icf  variables 
(pointers)  make  this  a non-trivial  task,  since  they  introduce  the  possibility  of 
aliasing ? languages  that  claim  to  be  verifiable  (eg.  I urlid  [lampson  7 7]) 
have  been  forced  to  deal  explicitly  with  the  aliasing  problem,  and  the  scoping  and 
parameter  passing  rules  of  Alphard  do  just  that 

In  addition  to  tire  existing  access  rules  of  Alphard,  we  impose  some 
restrictions  on  the  syntactic  form  of  handler  bodies.  We  require  that  the  body  of  a 
handler  consist  of  a single  procedure  call.  Neither  the  procedure  nor  the  call  has 
any  special  syntactic,  structure:  only  their  existence  is  prescribed.^  The  actual 
parameters  in  the  procedure  c dl  may  be  quantities  addrossible  within  the  handler's 
associated  local  context  or  parameters  passed  to  the  handler  by  the  signaller  (see 
section  4.4.2)  We  do  require,  as  with  all  procedures,  that  it  be  possible  to 


p 

* i e two  apparently  d»stmct  var,aNes  (e  g two  b - ai  j.vamet^'S  to  a p*  *»-•,*»)  may  a tually  be  the  r-ame  one 
(e  a thp  same  actual  ra*arreter  was  bound  to  both  fcrfr>ai$). 

^ We  hmted  at  such  / estnct'ons  in  section  4.5. 

^ We  note  that  this  is  only  a syntactic  restriction;  any  language  construct  that  behaves,  for  verification  purposes, 
like  a procedure  is  acceptable  here  Thus,  a syntax  macro  that  po*tetses  the  desired  proper!  es  could  he 
substituted  without  violating  this  restriction.  We  do  not  require  linkage  to  an  out -of  Ime  code  body.  This 
requirement  has  the  attractive  tide  effeci  o*  keep* 9 the  handle*  •‘•vtrnv<ve  ^ the  ehy  mating  it  eaty  for  a 
casual  reader  of  the  program  to  ignore 
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determine  from  the  source  text  which  parameters  are  read  and  which  are  written. 
The  notation  in  subsequent  sections  presumes  this  property  for  all  functions  and 
(internal)  procedures,  as  indeed  is  customary  for  verification  purposes. 

Finally,  we  ignore  the  verification  issues  raised  by  the  interac  tion  of  the 
exception  mechanism  with  parallelism  and  synchronization  facilities  of  the  language. 
Although  it  might  seem  that  in  doing  so  we  are  "throwing  out  the  baby  with  the  bath 
water",  we  should  observe  that  final  disposition  of  these  questions  requires  a 
formal  definition  of  parallel  processing  constructs,  which  is  not  yet  available  tor  our 
chosen  embedding  language.  Even  with  a precise  definition,  verification  of  parallel 
programs  remains  a difficult,  incompletely  solved  problem  and  is  the  subject  if 
considerable  current  research.  A detailed  treatment  of  these  issues  would  exceed 
the  scope  of  this  thesis. 


6.2  Predicates 

We  will  define  the  semantics  of  our  e xccptton  handling  constructs  through 
predicates.  In  general,  these  predicates  will  express  the  state  of  the  abstraction 
implemented  by  a particular  module  at  some  instant,  eg  just  before  or  after 
invocation  of  some  function  of  the  module.  The  user  of  the  abstraction  may 
presume  only  the  information  made  available  through  these  predicates  when 
verifying  his  program. 

The  existing  Alphard  methodology  already  defines  the  behavior  of  functions  in 
terms  of  pre-  and  pcist-conditions  (predicates  that  hold  before  and  after  function 
execution,  respectively).  We  extend  the  formulation  in  a natural  way  to  include 
pre-  and  post-conditions  for  exceptions  as  well.  Thus,  a module  that  defines  a 
particular  exceptional  condition  on  its  abstraction  also  defines  two  predicates  that 
hold  before  and  after  the  condition  has  been  handled.  Since  we  regard  handlers  as 
similar  to  external  procedures,  it  seems  natural  to  specify  pre-  and  post-conditions 


' This  is  all  That  *5  really  needed  We  an  dispense  with  the  requirement  that  the  handler  body  te  a single 
procedure  call  at  the  e»pense  of  havng  to  determine  more  circuitously  the  variables  it  manipulates  However,  the 
pr c.r  edur e call  requirement  keeps  the  handle's  small,  as  already  noled,  and  simplifies  the  pin  t 1 e as  v.ell 
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that  define  what  the  handlers  are  to  do.  The  crucial  difference  is  that  the 
specification  occurs  in  the  calling  module,  the  signaller,  not  the  module  that  defines 
the  handler  This  is  precisely  the  reverse  of  the  method  of  function  pe  ''  ■<  it  e 
which  the  module  that  defines  the  function  also  supplies  the  predicates.  io 
accommodate  this  difference  in  specification,  we  are  forced  to  alter  the  proof  rule 
for  procedure  colls  somewhat  in  adapting  it  to  handlers.  The  details  are  presented 
in  section  6.5. 

Thus  our  primary  tool  in  verifying  the  use  of  the  exception  mechanism  will  he 
the  pre-  and  post-conditions  on  each  condition  name.®  In  suhseguc  it  ns  we 

will  use  these  predicates  to  construct  proof  rules  for  both  • • j n II i • • • ; and  ha  ■ ig 
sites,  much  as  we  do  for  fum  tion  pre-  and  post-conditions  and  d<  fin  tion 
sites.  In  following  the  function  verification  paradigm,  however,  we  encounter 
phenomenon  of  using  a single  predii  ate  for  proofs  in  b th  th«  ict  and 

domains.  That  is,  when  we  prove  that  a tun  hen  sate  fi*-s  the  , 'u  i;  ■'  : t s 

pre-  and  post-conditions,  we  ire  proving  its  1 ehavior  within  the  men  m th  m a.s 

(i.e.  in  terms  ot  the  representation  it  nimvf  sates)  However  . \ '.he  cut;  •■•.to, 
are  using  the  predicates  to  define  the  behavior  within  tin  d ■ tract  domu-n. 
only  the  abstraction  is  available  to  the  user  of  a module,  i nr  e x;  ptior  Ice  .!■• 

the  identical  problem  arises  but,  because  of  the  inveted  nature  of  the 
specifications  (discussed  in  th.e  preceding  paragraph),  the  semarb. 
concrete  domain  are  required  to  verify  the  signalling  site  and  t < sei  - 
abstract  domain  apply  at  the  handling  site.  For  both  function  m . an  • <n 
exception  transmission  we  need  to  be  able  to  transform  i , du.  • t • wre.h  n 
describe  one  domain  so  that  they  are  suitablr:  tor  use  within  tl  . • other 

Alphnrd  solves  this  problem  for  fum  tion  invocatic  i by  tire  i < ol  a 

'representation  function',^  which  estahdshe.s  the  correspond1 -run  ••tv..  • n 

elements  of  the  two  domains.  We  appeal  to  the  sumo  mapping  * • » die  rmp'  .«••.  c 
exception  transmission,  lor  simplicity,  we  will  omit  explicit  rotor  nces  to  tin. 


c 

° The  unfortunate  do  Me  rr  « g 0f  1 1 »r*  r1  ' ■ • n"  is  h *i.»(  k al.  After  * • n *•  . » ' * v.  to 

«.ef f identifying  as  pre  or  j ^ »n • » • * . and  th*»  ,VT>b»G'»  ty  of  ••■Mi  »”  w»H  b* ■ r • ited 

/ Here,  '’function"  h ?s  th  e ' id  t *t  i »’•  .0  !»  • • • . . f ...  ...  j 
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representation  function  when  describing  the  proof  rules  for  the  exception 
mechanism.  We  will  assume  that,  where  necessary,  the  pre-  and  post -conditions 
have  been  transformed  to  express  properties  of  the  appropriate  domain  In  aght  of 
the  preceding  discussion,  it  should  always  be  clear  from  context  which  form  of  a 
particular  predicate  is  required. 


6.3  Notation 

In  the  remaining  sections  of  this  chapter,  we  develop  proof  rules  for  the 
exception  mechanism.  The  notation  is  conventional;  for  reference  purposes  we 
briefly  define  the  basic  symbols  used. 

The  lower  case  letters  x,  y.  z,  a,  v are  all  used  to  denote  sets  of  variables  < , 
y,  and  z always  denote  the  formal  parameters  of  a function  that  may  be  changed  by 
the  execution  of  the  function,®  1/  denotes  the  formal  parameters  whose  values  are 
inspected  but  not  changed,  a denotes  a set  of  actual  parameters  that  may  he 
legally  substituted  for  x.  y,  or  7,  i.e  parameters  whose  valuer,  may  he  changed. 
Tloments  of  a are  thus  simple  variables,  not  expressions,  e denotes  expressions 
that  may  he  substituted  as  actual  value  parameters.  Any  of  these  set  name;  may 
be  subscripted.  Since  the  values  of  a may  change  across  a function  call  we  will 
follow  the  usual  convention  and  write  a1  to  denote  the  "previous  vanes".  i.e.  the 
values  before  the  call.  It  is  occasionally  necessary  to  refer  to  sets  of  variables 
that  do  not  participate  in  an  operation.  When  the  need  arises,  we  will  denote  a set 
of  these  "constant"  variables  by  A. 

Function  names  are  denoted  by  f and  g.  Thus  a formal  function  specification 
might  be  f(x,-v),  an  actual  call  might  be  f(a;e).  In  this  notation  the  semi-colon 
instead  of  the  usual  comma  reminds  us  that  the  parameters  are  sets.  By 
assumption,  members  of  a never  appear  in  the  expressions  of  o in  suc.b  a call 

Condition  names  are  always  denoted  by  c,  and  handlers  are  denoted  by  h. 
Since  handlers,  by  assumption,  are  procedure  calls,  we  will  often  wide  h(a,e)  as  a 
specific  handler  body.  The  procedure  itself  will  naturally  be  written  h(x,-v). 

o 

The  <0  railed  "var"  parameters 
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Pre-  and  post-conditions  are  denoted  by  and  B^ost , respectively.  These 

will  generally  be  subscripted  by  function  or  condition  name  to  distinguish  them,  e g. 
Bfbrp  is  f's  pre-condition.  Other  predicates  (verification  conditions)  are  denoted  by 
the  upper  case  Roman  letters  P,  Q,  and  R. 


6.4  Proof  Rules  for  the  Signalling  Site 

We  can  now  present  the  proof  rules  for  the  raise  statement.  For  reasons 
noted  in  section  6.1,  these  rules  do  not  express  the  sequencing  of  handler 
invocation  except  as  it  relates  to  the  signaller.  Thus,  synchronization  interactions 
between  handlers  invoked  (potentially)  in  parallel  are  ignored  in  this  treatment.  We 
examine  each  of  the  selection  policies  of  section  4 7 1 in  turn. 


6.4.1  The  Br  oadcast-and- Wait  F'olicy 


This  policy  induces  behavior  extremely  close  to  a procedure  call.  All  eligible 
handlers  are  invoked,  the  signaller  waits  for  all  of  them  to  terminate,  then  execution 
continues  following  the  raise  statement  Indeed,  if  only  one  handler  is  eligible,  the 
effect  is  precisely  that  of  a procedure  call.  The  proof  rule  for  broodcast-and-wait 
is  slightly  more  complex  than  the  procedure  call  rule  because  it  must  ensure  the 
"condition  persistence"  property  discussed  in  section  4. 7. 1.9  This  is  the  only 
variation  (for  this  policy)  from  the  procedure  rule.  Because  the  rules  for  the 
remaining  selection  policies  are  all  derived  from  this  one,  we  will  briefly  examine  its 
intuitive  meaning. 

Refer  to  figure  6.1.  In  the  implication  above  the  line  (i.e.  in  the  premise), 
the  first  term  of  the  consequent  merely  requires  that  the  pre-condition  on  c be 
satisfied  when  the  raise  occurs,  a consequence  of  the  coi  ' tlon  persistence 
principle.  The  second  term  has  two  purposes:  io  complete  the  statement  of 
condition  persistence  and  to  force  the  post-condition  on  c to  establish  the 


Indeed,  all  proor  mjIp^  ror  thp  vanotis  "tpction  polic  es  -ni i 1 rio 
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necessary  state  after  the  raise.  Let  us  consider  the  implications  separately 
BcP"s<(w,a«,e)  Bcpre(w,e)  establishes  condition  persistence  by  ensuring  that  the 
order  of  handler  execution  is  irrelevant.  Since  no  manipulation  of  variables  (w)  that 
a handler  can  perform  is  permitted  to  invalidate  the  pre-condition  on  c,  no  handler 
will  be  invoked  by  this  raise  with  a false  pre-condition.  Viewed  somewhat 
differently,  this  implication  states  an  invariance  about  the  pre-condition  Bcpre. 
However,  note  that  the  invariance  is  conditioned  by  the  truth  of  P,  it  may  not 
(probably  will  not)  hold  globally.  Tire  other  implication,  Bcpost(w,a',e)  '■>  Q(\v.a',e,k), 
seems  to  require  that  Bcpos*  be  strong  enough  to  ensure  Q,  but  this  is  patently 
impossible  in  general,  since  Q makes  statements  about  variables  (k)  that  do  not 
even  appear  in  BcPos*.  Once  again,  we  must  recall  that  this  implicate  »n  is 
conditioned  on  P,  which,  by  the  definition  of  k,  makes  the  same  statements  about  k 
that  Q does.  In  this  context,  the  requirement  is  a reasonable  and  natural  one 
Obviously,  we  must  be  able  to  "carry  across"  the  raise  statement  any  information 
about  the  signaller's  context  that  cannot  possibly  be  affected  by  the  handlers 


Pte.e.k)  o FBcpre(a,e) 


Vu  IB  post (ui. 


o.  Q!u,a’,e.k)  a Br'jr  e Iw,  e)  1 1 


P(a,e,k)  Ira i se  c sunder  br oadcas t-and -ua i t > t Q(a,a'.e,k) 


Figure  6.1:  Proof  Rule  for  'Broadcast-anri-Wait' 


Sometimes  the  procedure  call  proof  rule  is  written  without  explicit  reference 
to  k,  but  an  axiom  of  the  verification  system  (called  "adaptation"  or  sometimes  the 
"frame"  axiom)  permits  it  to  be  extended  to  the  form  of  figure  6.1  Vve  prefer  to 
retain  the  expanded  form  because  it  emphasizes  what  can  be  altered  during  the 
exception-handling  process  and  what  must  remain  constant.  Of  course,  we  could, 
without  loss  of  generality,  eliminate  the  k's  in  our  proof  rules,  but  we  feel  that  the 
control  of  variable  accessing  during  exception  handling  is  of  central  Importance,  and 
we  prefer  to  represent  It  explicitly. 


105 


VERIFIABILITY 


CH  6 


6.4.2  Tho  Sequential-Conditional  Policy 

Although  from  an  operational  viewpoint  the  sequential-conditional  policy 
appears  quite  different  from  broadcast-and-wait,  their  proof  rules  are  rather  similar. 

This  is  not  too  surprising  in  light  of  the  observations  at  the  start  of  section  d.b.1 
that  the  effect  of  raising  conditions  (ns  distinguished  from  the  handler  selection 
algorithm)  under  these  two  policies  generally  differs  only  slightly.  Indeed,  it  the 
predicate  associated  with  the  raise  statement  under  the  sequential-conditionai 
policy  is  identically  false,  then  the  effect  is  precisely  that  of  broadcast- and- 
wait.^  Naturally,  this  collapsing  of  function  is  mirrored  in  the  proof  rules  as  well.  ' 

Refer  to  figure  6.2.  R is  the  predicate  that  appears  in  the  source  text  of  1 

the  signalling  program.  Note  that  P must  ensure  that  Ft  is  false  initially.  Wo  ceibd 
relax  the  semantics  to  permit  ft  to  he  true*  initially,  and  define'  the  ease  • . t it*  nt 
to  have  no  effect  in  that  case.  While  straight-forward,  this  niiinteM  .ling  case 
clutters  the  proof  rule  and,  in  practice,  never  arises.  Accordingly,  we  dr  ill  e * 

The  remainder  of  tire*  consequent  comes  directly  from  the  proof  rule  for-  broad- 
nnd-wait,  except  that  the  condition  persistence  requirement  s inlaxod  slightiv 
Because  selection  and  execution  of  a handler  occurs  only  if  R is  false,  we  rat  ruby 
require  condition  persistence  only  in  that  case.  Indeed,  the  handler  that  ca  r . s ft 
to  become  true  has  probably  caused  the  condition  to  disappear  1 1 Oner?  the 
condition  has  been  eliminated,  it  is  unreasonable  to  require  Bc(,re  to  hold. 


Of  nij r*e  inder  r n policy  the  handlers  r-r-  ,'n  p parallel  whhe  under  the  other  1‘oy  o»o  .te  • • * 

However,  this  rfif f er  r<ri(  e • % n t v < 'hie  to  tho  *!<;•- alter  "i  < ■ t alter  t * . c e M p ■* * it  per c.e tv  *•  s 

^ II  rnight  e . on  *epm  desirable  t have:  R(w,e)  5 e(w,e),  h it  thr?  is  too  strong  We  m j t t ' ‘ 

p 'dent  ■ r iiy  t »♦*  y el  ' av*  R dr ' rr  the  c-rne  t ■ - * e see  - 1 1 * p tor  m,  i.itf-n  p'!  cy  Rmh  "r  ' " . r *■  1 < 
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P(a,e,k)  d [-'R(a,e)  a Bcpre(a,e)  a 

Vu  (Bcpos*  (u,  a'  , e)  d.  Q(ui,a’,e,k)  a ->R  lu,  e)  oE!cpl  s (u  e)l] 


P(a,e,k)  Ir a i se  c until  R <under  seq-cond>l  Qta.a*  e,k! 


Figure  6.2:  Proof  Rule  for  'Sequential-Conditional' 


6.4.3  The  Broadcast  Policy 

The  proof  rule  for  the  broadcast  (without  waiting)  policy  appears  in  figure 
6.3.  This  rule  is  quite  easy  to  interpret;  it  states  the  condition  persistence 
principle  and  requires  that,  no  matter  what  the  handlers  may  do  (including  nothing), 
P is  strong  enough  to  establish  Q.  This  formulation  may  seem  too  restrictive,  for  it 
requires  that  signaller  and  handlers  act  nearly  independently.  However  these  arc 
precisely  the  semantics  we  desire!  the  broadcast  policy  is  normally  used  to  report 
to  the  users  of  an  abstraction  a purely  informational  condition.  As  an  obvious 
example,  consider  the  completion  of  an  I/O  operation.  The  signaller  (frequently 
hardware)  raises  the  condition  but  requires  no  explicit  action  by  the  user(s)  and 
proceeds  without  waiting  for  any  "reply"  Applying  the  rule  to  prac  tical  situations, 
we  find  that  the  sets  a and  w are  normally  empty,  and  that  frequently  s 

This  usually  leads  to  choosing  P-Q,  and  leaves  only  the  trivial  proof  that  P 
~>  6c,,re.  In  the  absence  of  interaction  between  signaller  and  handler,  condition 
persistence  is  easily  assured.1^ 


1 **  II  ir  possible*  lo  tela*  the  pioot  rue  r-nmewhat,  but  we  then  nsF  serious  into’ , lotions  with  pa'al'e'isrr.  and 
synchronization  me' hani  srr-s  Smi-p  we  have  chosen  to  avoid  such  p'obtemv  we  prefer  to  retain  the  to  m given  in 
figure  3 Its  semantics  comfortably  accommodate  th*  primary  applicabon  of  U o broadcast  policy  purely 
informational  signals 
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which  the  condition  could  be  raised.  For  flow  class  conditions  (the  example  used  to 
motivate  this  shorthand),  such  points  correspond  only  to  invocations  of  functions 
that  can  raise  the  condition,  but  for  structural  conditions,  literally  every  primitive 
operation  within  the  context  may  be  a potential  point  of  interruption.  ’ ^ For 
verification  purposes  we  transform  (conceptually)  the  source  text  so  that  every 
primitive  oper  ation  during  which  a condition  may  be  raised  has  the  relevant  handier 
directly  associated  with  it.  Thus  we  "copy"  the  handler  to  every  point  at  which  the 
condition  it  processes  can  be  raised.^  In  effect,  we  apply  the  eliq-biiity  rule  of 
section  4.6  to  determine  the  relevant  handler  for  every  condition  and  primitive 
operation  appearing  in  the  program  to  be  verified.  The  existence  of  at  least  one 
handler  for  each  condition  is  assured  by  the  assumption  that  a "default"  module- 
body  level  handler  always  exists,  even  if  the  programmer  fails  to  write  one 
explicitly  (see  end  of  section  4.5). 

The  second  syntactic  transformation  eliminates  local  transfer  of  control. 
Assuming  that  we  have  already  performed  the  first  transformation,  all  handlers  are 
now  associated  with  primitive  operations,  i.e.  function  invocations.  Thus  we  have 
constructs  of  the  following  forms- 

f ( X ; v J ) ( c : h ( y ; v 7 ) J ( >v ) 


and 


f(x;vj)  [c:  h(y;v-.)  ->  I eave  lab]  (>•<■*) 

where  'lab'  denotes  some  labelled  lexically  enclosing  context  within  the  current 
function  body.  Tor  the  purposes  of  our  proof  rule,  the  first  form  is  already 
acceptable.  We  replace  the  statements  of  the  second  form  by  the  following: 


We  are  considering  the  most  general  case.  in  which  parallel  activity  is  psesent  In  a purely  sequential  system, 
only  operations  thal  can  raise  the  given  condition  can  be  potential  points  of  interruption  except  for  the  purposes 
of  invoking  module  body  level  handlers.  These  latter  handlers,  in  a sequential  system,  interrupt  nothing  and  thus 
constitute  a special  rase 

1 d 

We  ignore  the  trivial  problems  introduced  by  scope  rules  and  redefinition  of  vai  allies  These  a>e  easily 
act  ortunc, dated  by  systematic  renaming  wtieie  nec  essary. 
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beqi  n 

pr i vate  b: boo  lean 
b *-  false 

f(x;vj)  (c:  h(y;VT);  b*-tr~ue] 
i f b t hen  I gave  lab 

end 

(Purists  may  wish  to  extend  the  set  y with  b and  place  the  assignment  of  'true'  to  b 
inside  the  body  of  procedure  h.)  It  should  be  obvious  that  this  transformation 
preserves  the  intended  operational  behavior  described  in  section  4.9.  Indeed,  the 
result  of  this  transformation  might  be  viewed  as  the  definition  of  the  notation  in  (**). 

By  means  of  these  transformations,  we  need  only  write  a proof  rule  for 
statements  of  the  form  (*).^  This  considerably  simplifies  the  task  of  describing  the 
formal  semantics  of  handlers,  but  it  raises  questions  about  the  practicality  of  the 
approach  We  defer  consideration  of  such  questions  until  section  6 6. 

6.5.2  Proof  Rule 

Refer  to  figure  6.4  Ignoring  the  lu  terms  for  the  moment,  we  see  an 
instance  of  the  procedure  call  rule.  This  is  merely  the  proof  rule  for  the  function 
invocation  f ( a i ' ; e -j ) . We  also  see  the  requirement  that  the  handler  h fulfill  the 
obligations  imposed  by  the  signalling  module.  These  are  exactly  what  we  expect  to 
have  to  prove,  but  we  must  additionally  account  for  the  interaction  of  h with  the 
surrounding  context. 

Since  we  do  not  know  a priori  whether  h will  be  invoked,  our  predicate  Q must 
lie  written  to  account  for  that  possibility  We  accomplish  this  by  requiring  h to 
supply  an  invariant,  1^,  that  holds  for  the  manipulations  It  performs.  Q < an  then  be 
constructed  using  the  knowledge  of  that  invariant.  However,  ns  is  evident  from  the 
proof  rule,  the  invariant  covers  only  a subset  of  the  variables  that  h can  manipulate 
(O'j,  not  a^,).  Let  us  examine  the  ramifications  of  this  formulation  of  the  invariant 

Assuming,  of  course,  that  we  have  proof  rules  for  the  othef  construct s (*»  g leave)  .nti  »n ,<  ori  by  the 
tr ansfot  mation.  In  light  of  th*  conventional  nature  of  these  constructs,  the  assumption  seems  quite  u-.u  r.,i!  e 
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P ( a , e , k ) o [ 1 ^ ( a^  . e^)  A 11  e (aj  . ej  ) a 

Vu,  z (8ff  °-’t  (y,  aj , ej  ) a 1 ^ ( z , e n ) .a  Q ( y , a ’ , e . k ) J ] 


a3,e2*  A Bc^' 6 BcBast  a lh(n.,.e9) 


P (a,  e,  k)  I f (aj  ; e j ) [c:  htaojep))!  Gla.a’.e.k) 

where:  a = aj  U a-,  and  e = t;  Of-, 

and  members  of  'a'  do  not  appear  in  mem;  >>.  s of  h ' . 
a3  = °2  ~ al • 

i.e.  33  = the  variables  that  ‘h’  hut  not  *f*  r 'n  cu.m  . 


f igure  G.d  Proof  Rule  for  a handler 


t lie  proof  rule,  in  effect,  says  that  if  1^  holds  hetu.e  f e.  invok  d ,o  ) tie 
execution  of  h preserves  l,v  then  after  f completes,  lh  will  still  hold,  and  we  may 
assume  its  truth  in  proving  Q.  This  rule  breaks  down  (terl"  > ally,  fn  runes 
unsound),  however,  if  l(l  refers  to  any  variable  that  f may  alter  he  a v mat.  . In 
a 1 )•  ,or  then  l(l  might  he  true  initially  but  be  invalidated  by  f bet  re  r is  raised 
Similarly,  lfl  might  hold  after  h lias  completed,  hut  it  might  become  false  through 
subsequent  actions  of  f If  lfl  js  restricted  to  the  set  a,  hownv  • < e n,  • 
invalidate  it  (since  a^  and  n t ,ire  disjoint  by  definition)  W<  s 'f  ■ in,,  tin  si 
mst i u to  is,  on  the  "scope"  if  th<  ariant  1^  do  not  if  t 1 ict  s h 
perform;  indeed,  a^  and  a->  will  frequent  . intere,  t and  >i  will  . •?.  , , it 

variables  in  the  intersection  Rathe*  the  eff.  < t is  t<  p„  . ,1  .<  , p I Wl.  Ig. 

available  after  f exi  ■ • . ' • ■ • 

variables  in  , l()  contains  inform  its  i at  mt  tae  vasal  es  n i . a.e  * m. 
n 3 • a ^ necessary  inf  ot  mat  ion  is  aval  d>ie  to  i j an*!  t > « • * > • i ^ n no  ,i  , M i . s i 
no  conflicting  information  can  result 

Now  let  us  examine  the  pn  of  run  ' ,i  f i*  , . i , , • . 

strong  enough  to  ensure  l(l  initially  Of  <Mir  ••  . t , . • <,  . *,  i,,t 

that  the  invocation  of  f be  legitimate  I he  v i t.  o . , • , * • , . 
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preceding  discussion,  namely,  ii'ti.u  dVss  o'  the  manipulations  performed  by  f and  h, 
tin’  truth  of  both  Ps  pc.t-  onrlition  and  ti's  invariant  (and  I’,  initially)  must  bo  strong 
enough  to  ensure  the  truth  ot  O the  second  part  of  the  proof  rule  is  nothing  more 
than  the  formal  statement  that  li  meets  ’lie  specifications  imposed  both  by  the 
signaller  and  its  invariant  This  verif  ation  will,  of  course,  involve  another 

application  of  tne  prnt  enure  < ' > ile  t shorn  I h»  noted  tint  we  have  omitted  the 
parameters  on  H(  ,>ro  and  h(  1 t /'!•  n j the  fotmul  ie 


t>.6  An  Assessment 

I Ins  i I apter  tiii'  pit  t * r ,iii  ti  , (.  uMhiiity  of  applying  formal 

verdu  ation  ter  hniqties  to  tin  ■ option  handling  met  hantsm  proposed  in  chapter  A 
At  sevi'ia  pond*  in  tie  p i • ■ a. it  ■ .wever.  wr>  tiave  commented  that  certain 
smg *lif a at ii ms  ha  . < ' • • el.  < ltd  irgne  ti  it  the  value  nf  tin*  result  is 

thi  teliy  dimn  i*. hod  r i erhai  that  tin  whole  problem  lias  been  "(issunmd  away". 
I ins  section  considers  the*  e issues 

I et  ii*  M s|  *.o  r I ' mn  a i I first  Ir  the  interest  of  r lardy  we  have  ignored 
the  provisions  of  section  A 4 . ttiat  conditions  may  have  parameters.  It  should  be 
i li*ar.  in  retrospect,  that  introdu*  mg  parameters  clutters  the  notation  slightly  but 
inriirs  rio  difficulties  Specifically.  HC,M'  and  can  be  extended  to  include 

lists  of  variables  changed  and  inspected,  and  indeed  in  section  6 A we  tiave  done 
so  Those  lists  were  suppressed  in  section  6.5  because  they  obscure  the 
manipulations  of  flip  local  context,  which  were  of  primary  interest  in  that  discussion. 
However,  it  is  easy  to  interpret  the  lists  x and  v in  h(x-,v)  ns  including  the 
parameters  "passed  through"  from  the’  handler  invocation. 

We  should  note  that,  although  the  eligibility  rule  of  section  A. 6 is  perhaps  the 
most  complicated  part  of  the  operational  definition  of  the  exception  mechanism,  it 
does  not  (need  to)  appear  explicitly  in  the  proof  rules  of  this  chapter.  This  is  an 
advantage  rattier  than  a deficiency.  The  first  transformation  rule  (see  section 
6.5.1)  permits  a verification  system  to  "reduce  the  scope"  of  handlers  to  a single 
operation,  and  in  so  doing  it  depends  implicitly  upon  the  eligibility  rule.  That  is,  the 
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semantics  of  the  eligibility  rule  ore  embodied  in  the  procedure  used  by  the 
verification  condition  generator  to  produce  (tie  set  of  expressions  of  the  form 

f (x; vj  ) [c:  h (y; v^) ) 

that  are  to  be  verified.  Thus,  in  fact,  our  proofs  do  rely  upon  the  eligilibility  rule 
implicitly,  since  the  above  set  of  expressions  is  determined  by  that  rule. 

A potentially  serious  objection  that  could  be  levelled  at  our  verification 
approach  is  impractic.ality.  In  many  cases  the  transformations  of  section  6 5.  1 will 
distribute  the  same  handler  to  hundreds  or  even  thousands  of  control  points  Wc 
may  naturally  question  the  practical  utility  of  such  a technique  in  terms  of  the 
present  mechanical  verification  technology.  However  we  should  observe  in  sin  h 
cases  that  the  set  <\p  of  variables  altered  by  the  handler  is  likely  to  he  small. 
Furthermore,  for  control  points  at  which  n-|  and  a . are  disjoint  (a  frequent  situation 
for  handlers  associated  with  a large  scope),  no  "extra"  work  is  induced  by  the 
presence  of  the  handler  It  should  he  possible,  therefore,  to  prove  certain  theorems 
(lemmas)  once  and  quickly  apply  them  to  the  majority  of  cases.  Intuitively,  the 
broader  the  scope  of  a handler,  the  less  it  is  able  to  manipulate  variables  with 
impunity  at  an  arbitrary  instant.  Thus  there  are  tew  "hard"  theorems  to  be  proved 
and  extens  e use  of  lemmas  can  eliminate  continual  "reproving"  of  the  same  trivial 
ones.  We  cl.  that  if  the  current  verification  technology  docs  not  have  the  ability 
to  avoid  such  mechanical  trivialities  by  discovering  and  utilizing  lemmas,  then  the 
iinpracticality  lies  in  present-day  verifiers  and  not  our  semantic  specifications. 

An  admitted  deficiency  of  the  proof  rules  is  their  failure  to  capture  certain 
synchronization  semantics  of  selection  policies.  Section  6.1  noted  the  reason  for 
this  omission.  The  problem  of  verifying  parallel  programs  is  a difficult  one  and 
distinct  from  the  exception  handling  issues  of  this  thesis.  We  suspect,  however, 
that  once  the  problem  is  solved,  the  missing  formal  semantics  for  selection  policies 
will  he  easy  to  supply,  since  their  informal  semantics  are  quite  normal  for  parallel 
processing.  We  depend,  therefore,  on  the  success  of  other,  independent  ir  <ireh 
to  provide  the  tools  necessary  to  complete  the  formal  definition  of  our  exception 
mechanism.  In  this  sense,  then,  we  do  not  regard  the  absence  of  sync  hroni/ution 
semantics  as  a serious  shortcoming. 
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We  believe,  therefore,  that  we  have  demonstrated  the  possibility  of 
constructing  an  exceptional  condition  handling  mechanism  that  is  amenable  to  formal 
mechanical  verification.  We  consider  this  mechanism  to  he  an  important  contribution 
to  language  design  because  it  enhances  the  expressive  power  of  a language 
without  compromising  verifiability. 
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"I  merely  wish  to  state,  avow,  affirm,  asseverate, 
maintain,  confess,  proclaim,  protest,  announce, 
vouchsafe,  and  say  that  there  are  precisely  ten 
such  tales  in  all,  and  each  and  every  one 
duplicates,  substantiates,  corroborates,  and  proves 
each  and  every  other." 

- James  Thurber,  The  White  Deer 

Having  seen  the  justification  of  the  exceptional  condition  mechanism  on 
methodological  and  verification  grounds,  we  new  demon'  trate  its  practi  al 
applicability.  We  will  show  by  example  that  the  mechanism  accommodates  in  a 
natural  way  several  exception  handling  problems  that  atisr  m "real-world"  systems 
and  that  are  not  successfully  handled  by  existing  mechanisms. 

In  section  3.3,  three  exception  handling  problems  were  presented  as 
examples  of  "real-world"  situations  that  the  mechanism  should  be  able  to  solve.  In 
this  section  we  examine  each  of  these  problems  in  turn,  as  well  as  some  others  that 
illustrate  specific  features  of  the  mechanism.  The  presentation  for  each  example 
includes  a prose  description  of  the  problem,  a coded  solution  using  the  exception 
handling  mechanism,  and  a commentary  that  discusses  some  of  the  more  subtle 
aspects  of  the  solution. 

I he  problems  as  posed  here  aie,  in  some  cases,  slight  simplifications, 
(localise  many  interesting  exceptional  conditions  have  far-reaching  effects  within  a 
system,  we  have  been  obliged  to  pare  down  the  examples  in  order  to  emphasize  the 
central  issues  they  address.  In  no  case,  however,  has  an  example  (knowingly) 
been  restricted  bec.ur  o the  exception  mechanism  rs  incapable  of  handling  a mere 
complex  case. 
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7.1  Example  1:  Symbol  Table 

For  our  first  example  we  present  a straight-forward  symbol  table  module,  with 
a few  minor  twists.  The  symbol  table  is  essentially  a content- addressed 
association  structure  of  bounded  size,  with  functions  that  add  a <name,vnlue>  pair 
and  retrieve  a previously  entered  pair.  We  consider  this  example  because  it  is 
self-contained  and  illustrates  some  basic  aspects  of  the  exception  handling 
mechanism. 


7.1.1  The  Symbol  Table  Problem 

Refer  to  figure  7.1.  The  specifications  for  a form  'symbol-table1  appear  in 
a style  close  to  that  used  for  Alphard.  In  fact,  our  symbol  table  example  is  an 
altered  version  of  the  one  in  [London  76],  with  the  block-structured  aspects 
removed  and  the  exceptional  conditions  added.  Briefly,  the  specifications  define  a 
'symbol-table'  to  be  a set  of  pairs  <s,v>,  where  the  first  elements  of  the  of  the 
pairs  are  all  distinct.  Further,  the  cardinality  of  the  set  is  limited  to  at  most  'n'. 
Note  that  both  condition  and  function  specifications  are  included,  with  pre-  and 
post-conditions  expressed  in  the  abstract  domain.  When  pre-conditions  are 
omitted,  they  are  assumed  to  be  identically  'true',  wh  n post-conditions  are  omitted, 
they  are  assumed  to  state  that  all  parameters  remain  unchanged. 


By  interpreting  the  pre-  and  post-conditions  in  operational  terms,  we  discover 
flint  the  'lookup'  function  leaves  its  arguments  untouched,  but  may  raise  either 
'absent'  or  'present'.  In  the  former  case  no  pair  with  the  desired  first  element 
exists  in  the  table.  In  the  latter  case,  however,  such  a pair  does  exist,  and  ttie 
parameter  to  'present'  is  the  pair's  second  element.  Thus  'lookup'  always  raises  a 
condition.  Contrasting  this  specification  with  the  more  usual  form  of  'lookup'  (as  a 
value-returning  function),  we  see  that  what  would  otherwise  appear  as  a part  of 
lookup's  post- condition  shows  up  instead  as  'present's  pre-condition.  This  is 
intuitive  and  comforting.  The  situation  for  'insert',  however,  is  somewhat  different. 
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EXAMPLE  1:  SYMBOL  T ABLE 


i T*  form  symbo  I - t ab  I e ( n:  i n t eger  , T : f orjn<  = , , V : f orm<  = ,*->)•= 

beg i n f or m 
spec  i f i co  t i ons 

requires  n > 1; 

I e |_t_  symbo  I - 1 ab  I e = as soc  : i <s : T , v : V>)  • 
i nvar i an t 

card i na I i ty (assoc)  < n 

a t j , t ->c  assoc  o ( 1 1 . c-  - 1 2 • ^ o tj.v=t2-v); 
in i t i a I I u symbo I - tab  I e = I ! : 

S f unc  t i ons 

I ookup ( s t : symbo I t ab I e , s tr : T ) 
rat  s e s 

absent  an  lookup  policy  broadcast 
pr  e = test  D t . S*S  tr , 
present  (v:V)  on  lookup  re! icy  broadcast 
pre  = Btist  §_t  t.s=str  a t.v-x 
enejr  a ise_s , 

insert  ( s f : symbo  I tablp,r>tr;i,valiV) 

raises 

— 

full  on  insert  policy  broadcast 

pro  = card  i na  I i ty  (s  t)  =n  a ( tc  stot . s*str  > 
endr a i ses 

POS  t_  norma  I = d ]tist  s_t  t . s=  s t r 

then  st  = s t ’ - 1 1 1 U l<str , va I >1 
else  st=st'U(<str,val>) 
pos_t  full  = st^st ’ ; 

Figure  7.1  Symbol  Table  Specifications 

Here  the  normal  pre-condition,  which  would  prevent  'insert'  from  being  invoked  who  t 
the  symbol-table  is  full,  is  relaxed  to  permit  unrestricted  calls.  The  former  pre- 
condition for  'insert'  now  becomes  the  pre-condition  for  'full'  instead,  suggesting 
that  a state  that  was  previously  assured  hy  a verification  condition  will  now  he 
assured  hy  an  explicit  test  within  the  function.  We  recognize  this  "delaying  the 
binding"  as  a means  of  ensuring  oporal ionally  correct  behavior  without  sacrificing 
formal  correctness.  Introducing  exceptional  conditions  that  reflect  an  invalid  state 
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r e|ir  esen  tot  i on 
un  i ciue 

namrs: vec  tor (T , 1 , n) . 
value'?:  vector  (V,  1 ,n)  , 
last: i n t eger 
ini t last*  0 : 

repl  last, names, values)  = Unames t i ) , va I ues ( i ] > I ic  (1» last] I ; 
i nvar ian  t 

I os  1 1 (0 , n]  a ( ( i , j t [ 1 , I as t ] a i * j ) a names [ i ] gnomes  [ j ] ) 

I mp  ! emen  t a t i on 

body  lookup  = 

first  j : upto (1 , I ast ) such V nj  names l j ] - s t r 
then  raise  present (va I ues l j]  ) 
else  raise  absent; 
body  insert 

out.  normal  = die  [1,  last.]  st  ( * /ics  [ i 1 s t r a values  [ i 1 v-  1 a 
V j c tl , I as  t ’ ] 3kc  ( 1 , I os  t ] s t 

(names  l j ] ’ -names [k] a , * j a va i ues  [ j ] va I ut  I k ] I ) 
ou  t full  « I a s t ’ - n a Vic  (1,  lo't*]  names  [ i ] * :•  tr 
bey  i n 

f i r _st  j : Up  t O 1 1 , I as  t ) SUCh  that  • • im*  [ j ] - s t r 
t hen  va  I ues  I j ] *-va  I 
else  j_f  la^tsn 

then  last*  I a s t + 1 ; names  [ last]  »-str;  values!  iii  t ] • v o I 
e I se  raise  full 

11 

end 

end  form 

Figure  ! .2:  Symbol  I able  Implementation 

at  function  invocation  normally  shifts  (part  ot)  the  function's  pre-condition  to  the 
ex cept ion's  pt e- condition. 

Wo  note  that  two  post-conditions  appear  tor  function  'insert'  This  notation 
merely  separates  the  part  of  the  post-condition  that  applies  in  the  "normal"  t ase 
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from  the  parts  that  apply  when  exceptions  hove  been  raised  The  actual  post- 
condition Is  a disjunction  of  these  terms,  i.e. 

(-  raised(full)  a post  normal)  v (raised(fuM)  a post  full) 

where  'raised*  is  a predicate  that  is  true  it  and  only  if  its  argument  condition  was 
raised  try  the  function  'insert'.  By  separating  the  terms  this  way,  we  see  more 
easily  what  actions  occur  under  various  exceptional  cases  without  having  to  wade 
through  long,  disjunctive  predicates. 

Now  refer  to  figure  7.P.  The  remainder  of  the  Alphard  form  contains  the 
representation  information  and  implementation  of  the  symbol  table  functions  The 
only  interesting  aspects  of  these  parts  are  the  use  of  the  raise  statement  in  the 
manner  described  by  the  predicates  in  figure  7.1  and  the  divided  output  assertion 
for  the  body  of  function  'insert'  The  two  portions  of  tins  assertion  correspond  in 
the  obvious  way  to  the  parts  ot  the  post-condition  in  the  abstract  specification 

The  code  fragments  of  figure  7 3 illustrate  possible  uses  of  'lookup'  and 
'insert'.  They  adhere  only  loosely  to  the  Alphard  syntax,  specifically,  the  separator 
within  square  brackets  has  none  of  the  usual  binding  semantics  and  is  used  only 
to  separate  the  component  parts  of  a handler.  The  invocation  of  'lookup'  sets  'v'  to 
the  value  associated  with  's',  if  any,  or  zero  if  's'  does  not  appear  in  ' t ' . The 
invocation  of  'insert'  expects  to  enter  the  pair  <t,w>  into  * t ' , but  will  leave  the 
block  labelled  'I'  if  the  table  is  full. 
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shared  t: symbol  tab  I e (47, str i eg, integer ) 
unique  r,s:string,  v,ui;  integer 


begin 


< set  ‘s'  > 

lookup! t,s)  [present (x) 


< use  v > 


/•-x  I absent:  v*  0] 


< set  ‘r’  and  ‘u’  > 
i nser t ( t , r , w)  [full: 


leave  I ] 


Figure  7.3-.  Sample  Use  ! - , 1 I able  Form 


7.1.2  Assessment 

Ibis  example  demonstrates  the  most  • ay  use  of  cxr  optional  oondith 

- to  specify  unusual  returns  from  a function  : >nuh  we  have  altered  the  obviou- 

specification  slightly  through  the  introdu.  tier  of  1 ■ condition  'present1,  the  solutin 
remains,  in  essence,  a finger -exercise  1 t it  mr.tr  itos  a point  raised  in  • t m 

1.1,  namely,  that  what  constitutes  an  e><  in  ( •mould)  bo  determined  try  th* 

user  of  an  abstraction,  not  its  implementor, 


In  most  of  the  remaining  example'  ' • . • • •••  with  a full  blown  Alpl.  • d 

form,  which  becomes  unnecessarily  v«  ••  tor  m purposes,  and  adopt  *»  ‘ 

conventional  syntax  for  some  of  the  In r r ru  t'  We  do  so  to  highlight  the 

exception  handling  aspects  of  the  exn  ! In  play  down  possibly  urifamii  ir 

aspects  of  Alphard  that  aro  not  er.  ,enti  t • n ' nulling 


tut  ■ hi  puoHises,  and  adopt  a nr  •- 
m t"  We  do  so  to  highlight  the 
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INCONSISTENT  DATA  STRUCTURES 


7 .2  Example  2:  Inconsistent  Data  Structures 

Section  3.3.1  suggested  that  the  exception  mechanism  should  handle  errors 
arising  from  memory  failure.  We  can  generalise  the  notion  to  include  all  situation.-,  m 
which  an  inconsistency  arises  in  the  internal  data  structure  of  a module  ana  the 
condition  cannot  be  repaired  hy  inherent  redundancy.  Certainly  a paii*  > ■ . i its 
this  classification^,  since  the  bit  pattern  in  a memory  word  is  demonstrably  viva  i 
hut  the  correct  intended  pattern  is  unknown  by  the  memory  system.  We  wili  bin  d 
upon  the  symbol  table  example  above  to  illustrate  this  class  of  errors. 


7.2.1  The  inconsistent  String  Problem 

Wo  suppose  that,  as  in  the  previous  example,  we  have  a symbol  table  tha. 
associates  strings  and  integers.  Suppose,  too,  that  whenever  the  content  of  a 
string  is  retrieved,  the  'string'  modulo  checks  its  representation  lor  validity,  if  the 
string  is  invalid  (e  g.  its  length  field  is  negative),  the  string  module  raises  a 
condition  'bad-string',  which  is  naturally  fielded  hy  the  symbol  table  module  We  w,ll 
alter  the  previous  version  of  this  module  to  maintain  a duplicate  vector,  'dnames',  of 
the  names  in  the  table.  We  will  then  add  handlers  to  perform  the  necessary 
recovery.  Refer  to  figure  74. 

The  string  module  defines  a function  that  copies  strings  and  a function 

that  tests  two  strings  for  equality.  Other  functions  of  the  module,  which  would 
manipulate  the  actual  contents  of  strings,  are  not  shown.  If  the  comparison  function 
" = " detects  any  inconsistency,  it  raises  'bad-string'  on  the  inconsistent  (instance 
of)  string.  Since  'bad-string'  is  structural,  it  goes  to  the  user  of  the  particular 
string  (in  this  case,  the  symbol  table  module).  If,  upon  return  from  the  handler,  the 
string  is  now  valid,  " = " continues,  otherwise,  the  string  is  reinitialized  and  the 
condition  'reset-string'  is  raised.  performs  identical  actions  for  each  of  its 
arguments. 

1 In  me  absence  of  error -correcting  codes,  of  course  Assume  trial  whatever  codes  exist  have  already  bne' 
applied  unsiK  c*>  vs  fully. 
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mojfu  I e s t r i ng  ( n : i n t eger  ) 
beg  i n 

private  length:  integer,  bar t : \ cc tor  I char ac  t er , 1 , n) 
i n i t I eng  t h*  0 

condition  r e 5 e t - s t r i n g pcj  u | broad  iM 
condition  bnd-str  ingtvar  s : s t r i ng)  ! ' 1 J hr  i 
f unc  t ; on  » ( e 1 , s 2 : 5 t r i ny ) 
b<  ] i n 

for  i : up  t o ( 1 , s2.  I eng  th)  do  si . char  s [ i ] «-  s2 . char  ■_  I J 

si. I ength<-s2. length 

end 

f unc  t i on  « (si  , ?2:str  ing)  ret'.---  h : h I > in 
raises  reset-sir  tq  on  si  , s2 
raiser  bad- string  cr'  si  , :-2 
beg  i n 

if  si . I ength<0 


ra  i se  si  . bar!  v tr  i t : i s 1 ) 
i f_  si  . I er  g th<0 

1 1 si,  • 1 1 • ( ■ 


’ring;  r 


i f s2  . I Png  t h<.0 
t ben 

raise  s2.  bad-  s tr  i < ( s . ' 

if  s2.  I enrj  t h<  0 

then  s2.  I eng  t h«-0 : • ■ - n 2 . - < • > t ~ ' r 

f i 

i f si . I em  j t h - ^ . I eng  t h 
* hen 

fir-  t i : up  to  ( 1 , si  . I eng  tb)  . tt  1 1_  r 1 . hi  ■ 
then  I »*  f a I se 
else  b*-  true 
else  b«  f a I se 


figi ire  t d ■ f mm  ’String’  wth  h xi  *g  t i n O ■ t • : 1 
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Now  consider  the  altered  version  of  'lookup1  that  appears  in  figure  7 5. 
(We  have  used  a less  terse  syntax  to  show  the  proper  placement  of  handlers.) 
Note  especially  the  'fixtable'  routine,  which  removes  the  clobbered  entry  from  the 
table  and  notifies  the  users  of  the  symbol  table  that  an  entry  has  been  lost  To 
accommodate  this  additional  condition,  the  post-condition  of  'lookup'  would  hav>-  to 
ire  extended.  We  omit  the  details,  observing  only  that  the  invariants  as  they 
appear  in  figures  7 A and  7.2  are  still  valid  despite  the  manipulations  of  'fixtable'. 


condition  lost  entry  policy  broadcast  nnd-uait 
f unc t i on  I ook  up ( s t , s ) 

t u : 1 ej?  lost  en  try  on  s t 
r a i se  s absent  on  lookup 
raises  present  (v)  ojt  lookup 
b e y i n 

f or  i : up  toll,  last)  do 

if  = (names  l 1 1 , s)  (names  [ i ) .bad-str  ing(str)  : s tr*-dnames  [ i ] 1 

then  raise  pr ecen t i va lues  1 i ) ) ; return 
f i 

nd  [names  ( i 1 . r cse  t - s t r mg : fixtableist.i)  -»  return  ) 

r o i se  absent 

end 

r ou  tine  f i x t ab I e ( s t : symho I - t ab I e , i : in t eyer ) 
beg  i n 

names  til*  names  f I ar  1 1 
dn a mes  [ i ] «-dnames  ( last] 
va  lues  i i ] <-va  I ues  II  ast] 

I a s t *- 1 a s t 1 
r a i • e st.  lost  -entry 

end 

T igure  7.5:  Re-implementation  ot  'lookup' 
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7.2.2  Assessment 

In  this  example  we  ; < < a • ut  t * excel  tioi  a m not 

present  in  the  'puri  symbol  table  ( *■  . int  i;  tl  e at  ion 

between  signaller  and  ha  h 1 is  1 r styli  of 

recovery.  Note  that  the  recovery  actions  <n  ply  to  tht  'n  imps'  data  struct  re  only; 
if  the  string  module  raise;  a mdition 

eligible.  I he  callei  ol  look  up'  is  a ui  1 1 sit  . , . parameter 

'lookup'  relies  on  higher-le vi  * • t • ■ < . . tions  < s' 

becomes  inconsistent 

Fhe  observant  reader  will  have  1 >oki 

st  i ing  rtu rdule)  raises  no  >tt  rs<  t 

implementation  of  strings  impose; 

it  prudent  to  avoid  1 1 i • the  i 

ideal  anyway.  I feguonh . when  t .In'  > n.iti  . > , . • . 

number  of  exceptional  condition;.,  i i.i  r , (v.  th  t 

st  r ncture ) will  cut  d< >v  the  potent  ... 

will  produce  a module  that  is  c ■ is  . o e i.  .r  to  ,i  . rn>  . 

would  better  serve  its  er;  an  entation  tha  ■ . 

arbitrary  length  string 


7.3  Fxamp/e3.  Arithmetic  Encepti  .>ns 

rhe  preceding  example  illust  • ■ ■ • ■ , i handlin' 

the  transmission  of  recovery  ■ t t ' v .gn  . u ■ , i i • . r 

Unfortunately,  the  communication  protom  ■ ,,t  •!<•., -uier!  by  the  d-  tails  of 

the  recovery  actions  In  th  ■ • f | | 

side  effects  that  are  fngi  • oily  as  ■ i.i' . I . iP  i , ■>  . y • "!  -d ! , • . • s the 

i ommunicnf ion  details.  We  coi  . I,  r c < . ,-!•  ,e  tl  admit  a 

variety  of  reasonable  recovery  ...  i.-it,  w • l<  n .mini]  the  • i , t . animal 

internal  state.  I he  inter, e ties  f e ,.|,  r I Is,  r thus  d . u,  ■ • -ed. 
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7.3.1  Floating-Point  Underflow 

We  omit  the  implementation  of  the  floating-point  arithmetic  form,  presenting 
only  its  (incomplete)  specifications  in  figure  7.6.  The  complete  specification  for 
this  module  would  naturally  include  additional  exceptions  and  functions,  but  the 
specifications  given  will  suffice  for  tins  example.  Let  us  briefly  interpret  ♦lie 
specifications  in  operational  terms. 


form  f p 

heq inform 
spec  j fj  i a t on ■ 
f one  t i on- 

add  ( a , b : f p ) retur  nr  r : f p 

r o± ses 

over  f I ou  ( vu'  v:fp)  n add  pel  icq  broadcast -and-ua  i t 
pre  * a+b>max tp 
endr  a i c er 

post  normal  = c*a  + b 
pns(  overflow  ■ c-v, 
maxfp  returns  c: fp 


f t 

Va 

a:  fp  :> 

r >a, 

m i epos  f p 

r f 

* ur  nr-  f : 

fp 

po  5 t - 

Va 

a:  fpAa 

• B ;>  d<c 

i a. 

d i v ( a , b : 

fp) 

r e t ur  n r 

c : f p 

r a i s i1  s 

ii  I*-  f I o t r I v a r v:(pl  on  cl  i v policy  br  oadc.as  t - and  - wa  i t 
1 r e (1-  I a/l  • n i npos  f p 
endr  a i res 

posi  normal  - c^a/b 
post  unrler  f I ou  = c = v, 
sign(a:fp)  return'  c: integer 

post  = if  a-0  t Ken  c-0  else  c = a/lal 


f igure  7.6:  (Partial)  I loating-Point  Module  Specifications 
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Two  constant-valued  functions,  'maxfp'  and  'minposfp1,  define  respectively 
the  larqest  and  smallest  positive  values  that  the  f p ' form  can  manipulate.  These 
semantics  are  clearly  given  by  the  post  - conditions  on  the  functions.  We  use  these 
functions  in  both  the  specifications  of  other  functions  of  the  'fp'  form  (e  g.  add 
and  ’div')  and  in  the  modules  that  use  the  'fp'  abstraction  (see  figure  7.7)  In 
the  'add'  function's  specifications,  'maxfp  n pears  in  the  definition  of  tire 
'over  f low'  exception,  whose  pn  i ndition  state  that  1 < > v * * r f lr  > w is  raised  if  the 
(real)  sum  of  the  arguments  to  'add*  ex  > ■ ds  e 1 plemented  range  (defined  by 
'maxfp').  Similarly,  the  pre-condition  on  ’ • ’ ■ > rf  (for  the  'div'  function)  states 

that  the  exception  is  raised  if  the  quotient  is  i t i iti<  illy  • but  i;  too  small  to 

be  represented,  i.e.  is  less  thar  mmposfp’  in  absolute  value. 


PC  i.  vote  x , y , z : f p 

z<-  add  ( x , y ) [over  f I nutv)  i v - '■  a < f i ] 

z«-d  i v ( x , y ) l under  f I ow  ( v)  : f 1 ;n lx  • >n  ! g ) 

then  v*-minpcsfp  e I ce  v*-  ir  i nposfp  fj_  ) 

z»-div(x,y)  [under  f I ou  (v)  : v»-01 

figure  7.7.  Use  of  Form  'fp' 


Now  let  us  examine  the  interaction  of  th<  exceptions  with  th<  I ' s 
raise  them.  Both  'add'  and  'div'  hove  the  same  structure  in  this  regard,  we  consider 
'add'  specif  ically.  By  definition,  'add'  aiways  return.',  a value  c • i*  in 
computation  of  'c'  depends  (possibly)  on  the  raising  of  the  'overflow  condition.  U 
'overflow'  does  not  occur,  then  the  "m  rmal  case"  post-condition  apf  lies,  ■ 1 
that  'c'  Is  merely  the  desired  sum  of  the  i arameters  to  'add*  However,  if  'overt  m 

does  occur,  the  post  condition  tells  us  that  'c'  is  set  to  whatever  value  v has.  We 
see  from  the  definition  of  'cv  'flow*  that  v’  is  a (vur)  par, in-  tor  [ .c. 
handler  of  the  'overflow'  con  liti.  n.  Thus,  in  the  event  of  overflow  the  1 .<>  .Her  has 
the  opportunity  (duty)  to  determine  thi  value  *.  f I it  a i 

examples  of  possible  handle:  n<  t ons,  t efei  t.  figure  7 7 
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7.3.2  Assessment 

We  must  not  forget  that  the  operations  performed  by  the  handler  in  otder  to 
compute  the  desired  return  value  occur  in  the  abstract  domain.  It  is  partly  for  this 
reason  that  the  functions  'rnaxfp'  and  'minposfp'  exist,  for  the  handler  requires  a 
representation-independent  way  to  obtain  the  largest  and  smallest  positive 
1 loat ing-point  numbers.  Even  the  zero  appearing  in  the  second  underflow  handler  is 
in  fact  an  abstract  version  of  the  floating-point  zero.  In  Alphard  quantities  that  are 
constant-valued  functions  may  be  defined  by  some  abbreviated  notation,  but  it  is 
the  concept  that  they  are  constants  with  abstract  properties  that  matters. 

We  note  that  the  actions  taken  hy  the  handlers  in  figure  7 7 are  rather 
conventional.  It  might  be  more  convenient  if  the  specifications  of  form  ' f p 1 indicated 
a fiequently  desirable  'default'  behavior,  so  that  handlers  might  he  omitted  if  the 
'default'  actions  is  acceptable  to  the  user.  For  example,  to  make  the  default  action 
on  underflow  be  'result  set  to  zero',  we  need  only  add  a term  to  the  pre-condition 
stating  'v  = O'  ^ Now  the  handler  is  relieved  of  the  duty  of  setting  'v'  to  zero  (in  the 
thud  example  of  figure  7.7).  The  handler  body  of  that  example  is  then  null  and  the 
enabling  construct 


[under  f I on ( v ) : ] 

may  be  omitted  entirely.  Obviously,  appropriate  default  values  may  be  introduced 
for  other  conditions  as  well.  While  this  is  not  a general  defaulting  mechanism,  it  can 
improve  readability  of  the  source  text  hy  cutting  down  on  the  number  of  handlers 
that  must  be  included. 

Handlers  may  wish  to  employ  mom  elaborate  recovery  strategies  than  those 
illustrated  in  this  example.  Underflow  in  a particular  floating-point  division  might 
necessitate  recomputation  using  arithmetic  that  offers,  say,  a wider  range  of 


N.st  -ally,  in  tho  imi  ’nr*  "rtlaLon  p.vt  nl  U^rrn  Ip,  Wf*  must  aim  inspif  ,n  Ihp  function  rW  Ihn  assiaiunf»ot  'v*-0'  just 

U>r»  'f,3  A 'if  <r»'flow(v)‘ 


1 27 


ADEQUACY 


CH  7 


representable  real  numbers.  To  perform  this  more  accurate  arithmetic,  another  form 
would  be  used  and  it  would  have  to  supply  transfer  functions  to  convert  between 
regular  floating-point  numbers  and  its  more  complicated  representation  We  have 
omitted  examples  of  such  usage  precisely  because  the  additional  state  manipulation 
blurs  the  essential  features  of  the  communication  between  form  ' f p ' and  the 
handlers  of  its  'underflow'  condition. 

We  note  in  passing  that  the  concept  'overflow'  may  be  applicable  to  more 
than  one  function,  e.g.  'add'  and  'div'.  Flow-class  conditions  with  identical  names 
may  be  specified  for  different  functions  of  the  same  module  without  wreaking  havoc 
with  verification  at  the  handler  site.  The  syntactic  transformations  of  section  0.5.1 
will  eliminate  any  possible  ambiguity,  though  they  may  as  a result  associate 
identical  handler  text  with  different  operations.  As  long  as  the  handler's  pre- 
condition is  weak  enough  that  it  is  implied  by  tire  exception's  pre-condition,  no 
inconsistency  arises.  While  such  a "trick"  might  seem  to  compromise  clarity,  in 
practice  it  can  reduce  the  number  of  separate  conditions  defined  by  a module, 
thereby  producing  a more  concise  specification. 


7 .4  Example  4.  Resource  Allocation 

In  section  3.3.2  we  briefly  mentioned  some  of  the  possible  exceptions  that 
might  be  defined  by  a resource  allocator  We  also  toyed  with  such  exceptions  in 
section  4.6,  promising  to  return  with  a fuller  treatment  I et  us  now  consider  the 
exception  handling  behavior  of  an  allocator  in  detail. 


7.4.1  The  Storage  Allocation  Problem 

For  definiteness,  we  suppose  we  are  specifying  a primary  memory  allocator. 
Fite  allocator  creates  and  deletes  storage  segments  specified  by  descriptors.  We 
ignore  the  details  of  descriptors,  noting  only  that  they  contain  a si/e  field  that  can 
he  manipulated  by  the  allocator  (by  calling  the  'descriptor'  module,  of  course). 
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The  allocator  provides  an  abstraction  called  a 'pool1,  whose  maximum  capacity 
is  established  at  instantiation  time.  (This  is  not  a crucial  property,  but  it  simplifies 
the  exposition.)  It  also  provides  two  functions,  'allocate'  and  'release'  'Allocate' 
accepts  a pool  instance  and  an  integer  size  ns  parameters  and  creates  a descriptor 
for  a segment  of  the  desired  size,  deducting  resources  from  the  specified  pool.  If 
adequate  resources  are  not  available  to  create  the  segment,  the  condition  oool- 
low'  is  raised.  After  tire  handlers  for  this  condition  have  freed  what  resources  they 
can,  allocation  is  again  attempte  d and,  if  unsuccessful,  fhe  condition  'pool-empty'  is 
raised  and  the'  allocation  request  fails.  The  'release'  function  has  no  exceptional 
behavior  - it  merely  returns  resources  from  a segment  to  the  pool.® 

We  assume  that  the  allocator  is  to  execute  in  a fully  parallel  environment  anc: 
must  therefore  provide  its  own  internal  synchronization.  We  use  mutual  exclusion 
semaphores  for  this  purpose  Refer  to  figure  7 0 for  the  code  of  the  allocation 
module.  We  offer  some  critical  comments  below  first,  however,  let  us  consider 
figure  7 9,  wliict  contains  a hypothetical  user  of  the  allocator. 

The  module  'nrb'  is  intended  to  illustrate  a possible  use  of  the  allocator  and 
performs  no  intuitively  interesting  operations  A caller  of  ' f ' supplies  units  of 
information  to  bo  stored  in  a data  base  of  some  sort  The  function  * f ' copies  tlre.se 
units  into  a segment,  which  it  obtains  from  the  allocator,  then  creates  a second 
segment  into  which  associated  retrieval  information  (computed  by  ' f ' ) is  stored 
Both  segments  are  then  entered  into  a complex  assoc. ation  structure,  namely  'm'. 
by  the  unspecified  procedure  'add-to'.  The  'nrb'  form  would  normally  ontain  other 
functions  besides  T - we  have  omitted  them  for  clarity 

'Arb'  claims  to  be  prepared  to  handle  'pool-lew'  at  any  instant  In  leed, 
except  dill  mq  the  time  when  seqments  are  I ■ • ■ t ’■>  'm  ■ <>l  lew'  ir-  h,  milled 

by  the  'squeeze'  procedure,  which  Inhon  ■,  •,  i • {l,f,  sjrl,  tore  m'  and 

releases  unnecessary  elements  to  pool  ' p ' IT>wPvpr,  it  is  crucial  that  the  two 
• euments  be  entered  into  'in'  indivisihly  with  tt  pert  > > mm  action,  hence  the 
invot  ation  of  'sq«  ~>ezel  is  inhibited  (by  a ma  king  h , lier  for  'pool-low'  that  does 


Wf  have  'h  Itorl  thf*  Irf*nlni6r't  of  ,i  p r^nti.i'  (Ii.iH  ‘"lit  -o  p 1 f t*  n H-* ipf 1 epf  s"ct  *n  A 3 Z I !o  avoid 
clt/t  to'  ing  the*  o * ,vt  ; o 7 y,  - * * o ,t  in  j . « •#.  , v rf*  »■  ^ .«  t r.< 
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>» 

modu I e pool (n) 
beg  i n 

cond i t i on  poo  I - I on  po I i eg  sequent i a I -cond i t i ona I 
cond i t i on  poo  I -empty  po I i cu  broadcast 
private  outer, inner:mutex,  free: integer 
< additional  fine  structure  of  a ‘pool’  > 
f unct i on  initial  i z e ( p : poo  I ) = 

(p.free«-n;  cinitialize  fine  structure:*) 
f unc  t i on  a I I oca  t e (p:  poo  I , am  t : i n t eger ) returns  d: descr  ip  tor 
r a i ses  poo  I - I ou  on  p,  pool-empty  on  allocate 
beg  i n 

macro  adequate  (p,  amt ) = p.free^anit  8 
P(outer);  P(inner); 
i f nql  adequate  (p,  amt ) 
then 

V ( i nner ) 

r a i se  pool- Ion  un t i I adequate (p, amt ) 

P ( i nner ) 

LI  hot  adequate (p, amt ) 

t hen  V ( i nner ) ; V(outer);  raise  pool-empty;  return 

11 

11 

p.  free  *-  p.  free  - amt 

< create  descriptor  'd'  for  segment  of  sire  ‘amt*  > 

V ( i nner ) ; V ( ou  t er ) 
end 

f unc  t i on  re  I ease  (p; poo  I , d:  de^cr  i p t or  ) 
beq  i n 

P ( i nner ) 

p.free  ♦-  p.free  + <size  of  segment  referenced  by  ‘d’> 

<release  space  associated  with  'd' ; reset  size  of  ‘d’  to  zero> 

V ( i nner ) 
end 

end 
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moriu I e arb 
b eg  i n 

shored  p:pool 

private  m: hairy- list  structure 
concl 1 t ' on  nosoap  pel  i c_y  broadcast 
f unc  t i op  t ( c t : mt  ecier  , < i n f o> ) 
r a i ses  nosoap  on  f 
beg  i n 

pr  j vo  to  dl , d" : descr i p tor 

macro  I oca  I -c I eangp  = re  I ease (dl I : rajse  noscap  S 
dl  *-a  I I ocate  (p,ct ) [poo!  empty:  rai  se,  nosoap  -*  return  ] 
d2*-a  I I oca  t e ( p . t+47)  [poo! -empty:  I oca  I -c  I eanup  -•  return  ] 

< f • I I in  dl  and  d2  using  <info>  > 
heg  i n 

add- to (m, dl ) ; add-tolm.dZ) 
end  [|  oo  I - I ou:  1 

end 

rout  i rig  squeeze 
bea  i n 

< perform  da*  i de; "ndent  compaction  of  ‘m’,  using 

‘ r e I ease  (p , d ) ' to  release  ang  elements  ‘ri*  removed 
by  compacting  ‘m’  ? 

end 

end  [pool -low:  squeeze!)] 

Figure  7.9:  Use  of  I orm  'pool'  ] 

nothing)  while  they  are  being  entered.  The  handlers  for  'pool-empty'  are  straight- 
forward - they  merely  translate  the  condition  name  to  one  appropriate  to  the  'arb' 
abstraction  and  propagate  it  to  the  curlier  of  ' f ' . I 
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7.4.2  Assessment 

The  code  in  figures  7.8  and  7.9  illustrates  the  interaction  between  the 
exception  mechanism  and  semaphores  for  synchronization.  Wore  it  not  for  the 
existence  of  condition  'pool-low',  a single  semaphore  would  suffice  to  ensure  mutual 
exclusion  of  invocations  of  'allocate'  and  'release'  on  the  same  pool  Because  we 
must  petmit  'release'  to  be  invoked  as  a result  of  raising  'pool-low',  two  semaphores 
are  necessary,  one  to  do  the  normal  mutual  exclusion  ('inner'),  the  other  to  prevent 
re-entry  to  'allocate'  ('outer').  I he  naive  approach,  with  a single  semaphore 
protecting  the  bodies  of  the  two  functions,  leads  to  a deadlock  when  'pool-low'  is 
raised  and  'release'  is  invoked  from  a handler  It  would  be  desirable  if  more 
sophisticated  constructs  were  available  to  permit  a more  natural  expression  of  this 
interaction.  (Recall  the  observations  of  section  ? ) 

We  should  note  that,  although  the  'pool'  module  is  prepared  to  handle  parallel 
activity,  'orb'  is  not  Multiple  instance's  of  'arb'  having  distinct  'hairy— list- 
structure's  would  execute  correctly  hut  multiple  simultaneous  instances  of  ' f ' 
applied  to  the  same  instance  of  'arb'  would  not  function  properly.  I he  eligibility  rule 
in  such  a case  would  still  permit  'squeeze'  to  be  triggered  in  one  instance  of  ' f ' 
while  another  was  attempting  to  perform  the  supposedly  indivisible  compaction  of 
'in'.  To  eliminate  this  difficulty,  an  explicit  'updating'  flag  and  appropriate  mutual 
exclusion  would  have  to  be  introduced.  In  general,  replacing  the  implicit  state 
encoding  (i.e.  the  masking  of  'squeeze')  represented  in  an  instantaneous  flow  path 
by  an  explicit  encoding  (i.e  a flag)  represented  by  an  element  of  the  data 
structure  leads  to  a clearer,  if  slightly  more  verbose,  program.  We  have  simply 
ignored  this  (rather  commonplace)  difficulty  by  assuming  the  situations  that  require 
such  data  structures  do  not  arise  in  our  example* 
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7.5  Example  5:  I / O Completion 


As  wc  discussed  in  Sf'Ction  3.3.3,  input / output  completion  may  tip  regarded  as 
an  exceptional  condition  Although  this  example  overlaps  somewhat  into  the  areas 


of  inter  - process  communication  and  synchronization,  it  illustrates  that  the  exception 
m e c hamsni  may  apply  naturally  to  situations  in  which  an  expected  event  ■Tr'ius 
relatively  infrequently. 


7.5.1  The  Real-Time  Update  Problem 


We  recall  the  example  of  section  3.3  3 Suppose  we  have  a collection  of 
asynchronous  processes,  one  of  which  accumulates  data  from  external  sensors  in 


nn  niiplane.  fhe  remaining  processes  perform  calculations  that  aie  priority-ordered, 
so  that  if  now  sensor  data  arrives,  they  are  to  begin  anew  with  the  more  recent 
input  rattier  than  complete  their  calculations  on  the  old  data.  In  this  way,  the  most 
important  quantities  are  calculated  as  soon  ns  possible  when  updated  information  is 
received.  1 c>  complicate  mntteis  slightly,  however,  some  calculations,  once  begun, 
must  run  to  completion.  In  a practical  application  this  can  arise  if  we  need  to 
ensure  that  a set  of  values  <x.y.z>  representing  the  computed  position  of  the 
ait  ( raft  r ,d<  halt'd  usual  a single  buffet  of  data  Permitting  the  calculation  of  this 
position  to  he  ini'  rruptrd  could  r<  suit  in  im  insistent  co-ordinate  values. 


Refer  to  figure  f in  The  function  'cjrindl'  represents  one  of  the 
computati  >nal  processes,  which  all  share  nn  instance  'but'  of  the  abstraction 
•sensor  buffer'  fins  abstraction  is  implemented  rlsewhoie,  all  that  concerns  us  in 
this  example  is  the  strut  tural  condition  'now-data',  which  is  raised  when  new 
values  have  been  placed  in  the  sensor  buffer.  flip  condition  is  broadcast 
asynchronously  to  all  users  of  'but'  (i.e.  the  selection  policy  is  broadcast).  As 
results  are  computed,  they  lire  placed  in  the  output  structure  'display',  another 
externally  - defined  abstraction  which  all  the  'grind'  functions  share.  I hose  results 
are  transmitted  by  the  'screen'  module  to  a physical  output  medium. 
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8 
9 

10 
1 1 
12 

13 

14 

15 
1G 

17 

18 
19 


modu  I e crunchers 
beg  i n 

shared  buf: sensor  buffer 
shar ed  d i sp I ay: screen 
f unct i on  grindl  = 
uh i I e true  dp 
I : beg i n 

pr  i vat  e r es  1 n t : t ' < ,r- 
restar  t*-  f a se 

< perform  computation  1 > 

< perform  computa*  > ’ > Ineu-data.  estar  t«-  true! 

i f restart  I p^ve  I * i 

< per  f r.»r  m . r mputat  i 


end  (new -data:  « leave 

function  grind?  r 

< similar  to  ft f above  > 


end 


Fiyuro  f 10:  al-lime  Computation  Module 


We  identify  two  *> t y i < f r t,i'  n < itru  y withm  the  'grind1  functions. 
Ihe  first,  typified  by  line  10.  i i tie  rt.  I anywhere  Note  that  if  'new-data'  is 
raised  when  control  is  at  line  10  (or  1 u i the  handler  on  line  1 5 will  be  invoked  and 
will  cause  control  to  transfer  to  the  start  of  the  loop.  The  second  style  of 
computation,  typified  by  lines  1 1 and  12,  cannot  tolerate  abortion.  Accordingly,  o 
handler  is  supplied  on  line  1 1 (masking  the  < ue  on  line  15)  that  prevents  transfer  of 
control.  However,  it  sets  a boolean  variable,  whs  h is  tested  after  the  computation 
is  finished.  In  this  way,  multiple  related  output  values  may  be  computed  without 
fear  of  interruption  and  subsequent  inconsistent  display. 
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7.5.2  Assessment 


We  have  ignored  the  fine  structure  of  the  computations  becatise  it  is  largely 
irrelevant  to  the  exception  handling  aspects  of  the  example  However,  since  we 
are  using  the  mechanism  for  inter-process  communication,  synchronization  is  c. 
relevant  issue  and  the  fine  structure  necessarily  involves  some  synchem,  ation 
Specifically,  each  computation  will  require  accesses  to  1 t»u f ' to  reunite  raw  input 
data  These  accesses  will  have  to  he  synchronized  within  the  sensor  buffer' 
module  to  prevent  the  asynchronous  arrival  of  sensor  input  from  producing 
inconsistent  values.  Assuming  tins  difficulty  to  be  resolved,  the  ct  r . n cf ' 

c omputations  may  assume  they  receive  proper  data  from  the  buffer  Compulation 
t hen  ensue  using  the  raw  input  If  all  related  results  are  computed  before  any  ere 
output,  the  'new-data'  condition  need  be  masked  (as  on  line  11)  only  win  n ' rose 
(locally  stored)  results  are  actually  being  transmitted  tr>  the  'display'.  Thus  the? 
eligible  life-time  of  the  handler  may  in  practice  he  very  short  - the  duration  of  Mre 
'output'  phase  of  a computation. 

The  explicit  masking  of  an  asynchronous  condition  and  use  of  a boolean  to 
recall  its  occurrence  reminds  us  of  conventional  interrupt  processing  when  an 
interrupt  must  be  held  pending  Usually  this  is  done  by  dedicating  a piece  of 
hardware  to  a polling  task,  polling  for  tire  unmasking  of  the  interrupt  here  we  are 
doing  the  same  thing  in  software  with  an  explicit  test  All  software  masking  is 
performed  this  way,  by  checking  at  "unmasking  time"  to  see  if  the  condition 
occurred  during  the  masked  interval  The  frequency  with  which  this  programming 
construct  appears  suggests  that  it  might  constitute  a usage  paradigm  in  the  sense 
of  section  5.2.  It  would  be  desirable  to  provide  appropriate  syntax  to  handle  this 
common  situation. 
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7.6  Summary 

The  preceding  examples  demonstrate  the  flexibility  of  the  proposed  exception 
handling  mechanism  as  a practical  tool  in  solving  "real-world"  problems.  Although 
the  situations  presented  have  been,  in  most  cases,  simplified  versions  of  actual 
problems  that  arise  in  operating  systems  and  application  programs,  tne  individual 
"assessment"  subsections  have  indicated  what  simplifications  were  made  and  how, 
in  practice,  they  might  be  overcome.  We  have  not  attemnted  to  flesh  out  the 
details  of  every  case,  but  rather  to  illustrate  the  power  and  scope  of  the 
mechanism  by  representative  examples.  We  thereby  support  the  claim  that  the 
uniform  application  of  the  particular  semantics  we  have  chosen  for  our  exception 
handling  mechanism  has  practical  value  throughout  a programming  system 


8 

Practicality 


As  the  final  stage  in  our  justification  of  the  proposed  mechanism  of  chapter  4, 
we  address  the  problem  of  implementation.  A detailed  description  of  an 
implementation  would  require  us  to  delve  into  the  workings  of  a specif  k 
programming  language  and  would  carry  us  rather  far  from  the  p'lin.  y t JP" 
Besides,  the  obvious  candidate  language,  Alphnrd,  does  not  have  an  implementation 
to  date.  To  substantiate  our  claim  of  practicality,  however,  we  must  show  nfurmally 
at  least  that  a reasonable  implementation  is  possible.  In  this  chapter  we  sketch,  in 
general  terms,  the  main  features  of  an  implementation. 


8.7  Handler  Bodies 

Most  of  the  elements  of  the  mechanism  have  obvious  implementations. 
Handler  bodies  are  compiled  much  the  way  procedures  are  (or,  if  one  adheres  to  the 
syntactic  restrictions  of  chapter  6,  the  way  procedure  calls  are)  the  only 
significant  problem  is  access  to  the  local  variables  of  the  interrupted  (associated) 
context.  In  an  ALGOL-like  language  with  a run-time  display,  tins  problem  is  easily 
solvrd  - Hie  handler  body  behaves  much  like  an  inner  block  and  the  display  ;ells 
other  than  tire  top  one  rue  identical  to  those  ot  the  associated  context,  i 'e  top 
display  cell  points  to  the  local  context  of  the  handler,  it  any.  Some  lightly  non 
standard  display  manipulations  may  be  required  at  handler  invocation,  but  those  arc* 
minor  details  If  the  language  does  not  use  a display  (e  g BI.ISS)  but  can  determine 
the  location  of  all  variables  relative  to  the  top  of  the  run-time  stack,  the  accessing 
of  loc  al  context  information  from  within  the  handler  becomes  more  ddfu  tilt  Now  two 
disjoint  stark  regions  must  be  accessed,  in  effect  a two-level  display  However, 
since  the  pointer  to  the  associated  context  will  be  available  at  handler  initialization 
(see  section  8.?  1 ),  it  is  straight-forward  to  compile  handler  code  that  accesses 
the  associated  context  relative  to  that  pointer  and  its  own  local  variables  relative 
to  the  top-of-stack  pointer.  In  fact,  if  the  handler  body  is  constrained  to  tie  a 
procedure  call,  the  former  pointer  will  be  necessary  only  to  access  the  variables 
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needed  as  parameters  to  the  call.'  This  implies  that  the  cahed  procedure  can  be 
compiled  normally  - a considerable  simplification. 

local  transfer  of  control  is  also  quite  straight-forward  We  want  to  achieve 
the  effect  of  a goto  to  an  appropriate  iocnl  address  upon  return  from  the  function 
invocation  that  has  been  interrupted  by  the  handler.  If  function  invocations  are 
implemented  as  subroutine  calls,  this  amounts  to  altering  the  stacker!  return 
address.  Thus  the  implementation  need  only  assure  that  the  location  of  that  return 
address  is  obtainable  when  the  handler  is  executing,  a requirement  that  is  easily 
satisfied.'5  We  observe  that  the  compiler  can  determine  which  function  invocations 
can  possibly  be  interrupted  by  a handler  specifying  a local  transfer  of  control,  and 
any  additional  code  required  to  make  the  return  address  available  need  be 
generated  only  for  those  invocations. 

8.2  Eligible  Handlers  Set 

The  only  significant  implementation  difficulty  is  the  eligible  handlers  set  Here 
the  goal  is  to  minimize  the  cost  of  maintaining  the  set,  perhaps  with  some  higher 
cost  at  search  time.  There  are  really  two  parts  to  the  problem:  maintaining  the 
'enabled  handlers  set'  (in  the  terminology  of  section  4 6),  and  determining  at  a 
given  instant  which  of  the  ’enabled1  handlers  are  eligible  Let  us  consider  each  of 
these  problems  In  turn 


1 And  perhaps  to  alter  a repjrn  address  to  effect  a local  transfer  of  control  See  next  paragraph. 

? Tor  example,  this  location  ran  be  at  a h»ed  p!ace  in  the  activation  record  for  the  i-  ntext.  Sure  a pointer  to 
that  activation  record  must  he  available  to  the  e«ecuhng  handler  anyway,  local  transfer  of  control  is  easdy 
effected. 

In  some  implementations,  if. ere  may  tie  no  additional  cost  in  supplying  the  no'  essary  location. 
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8.2.1  Enabled  Handlers 


The  enabled  handlers  set  can  be  partitioned  into  two  subsets:  those  handlers 
declared  at  the  module  level  and  those  that  appear  within  function  bodies.  I he 
former  are  enabled  when  their  associated  modules  are  instantiated,  the  latterr  are 
enabled  while  control  resides  within  their  associated  contexts.  We  will  represent 
these  sets  by  lists.  Fach  list  element  on  these  lists  will  represent  an  enabled 
handler  and  will  contain  at  least: 

a link  field  (to  point  to  the  next  list  element),^ 

a context  pointer  that  identifies  the  associated  context  (e.g. 

points  to  an  activation  record  - see  discussion  in  section  8.1  ), 

a handler  pointer  that  identifies  the  code  of  the  handler  body, 

and 

a unique  nerve. 

The  unique  name  field  is,  in  effect,  a token  that  represents  a user,  as  we  shall  see 
shortly. 

Now  we  can  distinguish  two  cases:  'flow'  and  'structure'  class  conditions 
Flow  conditions  constitute  a special  case  and  can  be  easily  dismissed.  Mrst, 
module-body  level  handlers  for  flow  class  conditions  can  always  be  "distributed"  to 
function-body  level,  by  virtue  of  the  shorthand  notation  (see  section  4.b).  This 
eliminates  the  need  for  a module-body  level  list  for  flow  class  conditions.  Second, 
all  enabled  handlers  for  a given  condition  and  function  instance  must  appear  in  the 
same  process  stack,  by  definition.  This  suggests  a simple  implementation  for  all 
flow  class  conditions,  which  is  essentially  similar  to  the  one  used  in  HI  ISS.  With 


a There  may  actually  he  two  link  fields  in  the  event  that  a doubly-linked  list  is  deemed  deniable.  See  subsequent 
cfi '.c ufV'H  of  'structure1  class  conditions. 
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each  process,  we  associate  a single,  distinguished  cell  that  will  act  as  the  list 
header  for  flow  conditions.  Within  each  process  stack,  we  link  all  enabled  handler 
list  elements  together  (for  'flow'  conditions  only!)  in  stack  order.  In  the  unique 
name  field  of  each  list  element,  we  insert  a value  that  uniquely  identifies  the 
condition  name.'*  As  we  will  see  below,  it  Is  now  a simple  matter  to  determine 
eligibility  for  any  flow  class  condition 

'Structure'  class  conditions  are  more  difficult  - troth  kinds  of  list  are  needed 
to  maintain  the  enabled  handlers  set  lor  structural  conditions,  the  headers  for 
these  lists  appear  in  the  instance  to  which  the  handlers  are  attached.  (Hecali  from 
section  4.11  that  access  to  these  lists  is  controlled  by  a mutual  exclusion 
semaphore  or  similar  synchronizing  construct  ) *’ 1 unique  name  field  ol  each  list 
element  contains  a value  that  identifies  the  instance  of  the  module  containing  the 
handler.®  Now  the  module-body  level  handlers  for  a qiven  condition  and  (data) 
instance  are  all  linked  together  in  no  particular  order  and  the  list  is  updated 
whenever  a referencing  instant  e (i  e one  :onti  ining  a 1 • : dir  ■ with  a module-body 
level  handler  is  created  or  destroyed.  For  handlers  witlnn  tunrtion  bodies,  however, 
the  list  maintenance  occurs  more  frequently.  The  list  structure  depends  to  some 
degree  on  the  number  of  pro-  esses;  wo  will  consider  a general-case  implementation 
that,  under  particular  language  restrictions,  could  be  optimized  sul  stontially. 

A second  list  exists  for  all  non-module -body  level  handlers  (for  a given  data 
instance  and  condition).  Call  this  the  DCl  - Dynamic  Context  I ist.  When  a context 
is  entered  that  has  such  a handler,  a list  element  is  allocated  on  the  process  stack 
and  filled  in  with  the  above  information.  One  additional  datum  is  included,  a unique 
value  identifying  the  function  instance  in  which  the  context  exists.  (This  is  in 
addition  to  the  unique  value  identifying  the  module  in  which  it  exists.  The  value  of 
the  stack  pointer  at  function  entry  will  serve  as  a unique  identifier.)  The  element  is 
then  linked  onto  the  front  of  the  DCL.  Note  that  the  effect  is  to  have  several 

5 

This  is  easily  and  cheaply  accomplished  by  compiler/link  et  cooper  at  on,  no  run  time  allocation  is  no  essary. 

^ Conceptually,  we  produce  a separate  copy  of  the  code  every  time  a module  ts  instantiated  In  fact,  all  we  need 
is  a unique  number  to  keep  track  of  instantiations  Thu  number  can  be  y»ne'ated  in  any  one  cf  several 
satisfactory  ways;  a particularly  convenin'  t method  is  suggested  ir  the  new l so  bon 
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separate  stacks  (one  for  each  process)  all  "woven"  together.  When  a context 
liavinq  such  a handler  is  exited,  the  element  is  unlinked  from  the  DCL  and  destroyed 
(popped  from  the  process  stack).  Note  that  if  the  list  is  singly-linked  this  will,  in 
general,  require  a search.  However,  by  addiny  a second  link  field  and  maintaining  a 
doubly-linked  list,  both  entry  and  exit  times  become  fixed  arid  independent  of  the 
interleaving  in  the  list.  Of  course,  entry  time  becomes  slightly  greater  (2  additional 
fields  to  change),  but  this  sacrifice  is  probably  worth  the  benefit  (of  fixed,  known 
cost)  reaped.  T htr  two  lists  now  maintain  the  enabled  handlers  set  for  a structural 
condition. 


8.2.2  Eligible  Handlers 


Given  the  enabled  handler  lists  as  defined  above  at  some  instant,  we  can 
determine  the  eligible  handlers  set  for  flow  conditions  the  task  is  straight-forward: 
we  simply  follow  the  links  back  through  the  current  process's  enabled  handlers  list 
for  flow  conditions  until  we  find  the  first  element  whose  unique  name  field  matches 
the  condition  being  raised.  This  element  is  the  only  eligible  handler.  Indeed,  we  can 
lie  certain*7  that  this  list  element  will  appear  in  the  segment  ot  the  process  stack 
allocated  to  the  invoker  of  the  signalling  function,  and  if  that  segment  is  readily 
identifiable,  we  may  bound  the  search.  In  any  case,  the  algorithm  is  obvious. 

For  structure  class  conditions  the  task  is  more  complex.  The  algorithm 
appears  in  figure  8 1.  SCL  stands  for  'Static  Context  list',  i.e.  the  header  for 
the  module-body  handlers  list.  DCL,  as  previously  mentioned,  stands  for  'Dynamic 
Context  list'  and  is  the  header  for  the  handlers  appearing  in  function  bodies  l he 
relevant  fields  are: 

next  - the  (forward)  link  to  the  next  list  element , 

mi  - the  unique  name  identifying  (hr1  module  instance  containing 
the  handler, 


' Except  in  certain  pathological  ca<es  where  a t'lnclion  name  is  passed  as  a parameter  Not  all  languages  permit 
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fi  - the  unique  name  identifying  the  function  instance  containing 
the  handler  (meaningless  for  elements  of  the  SCI ),  and 

mark  - a boolean  flag  (initially  false)  used  internally  by  the 
algorithm. 

Let  us  briefly  examine  the  operation  of  the  algorithm.  Recall  that,  by 
assumption,  the  SCL  and  DCL  are  protected  by  a mutual  exclusion  semaphore.  Thus 
the  lists  cannot  be  altered  during  the  execution  of  this  algorithm  We  will  generate 
the  members  of  the  eligible  handlers  set  one-at-a-time  in  an  m specified  order. 

The  search  for  eligible  handlers  extends  from  lines  1 to  30  and  consists  of 
two  pans.  Lines  3 to  22  locate  eligible  handlers  on  the  DCL;  lines  23  to  29  locate 
eligible  handlers  on  the  SCL.  1 he  'mark'  field,  if  true,  indicates  that  the  list  element 
corresponds  to  a masked  handler  (in  the  sense  of  section  4.6),  i.e,  an  ineligible, 
enabled  handler.  Initially,  all  'mark'  fields  are  false,  and  the  algorithm  restores  that 
state  upon  completion 

The  search  of  the  DCI  involves  finding  the  lexically  innermost  handler  within 
each  distinct  module  and  function  instance  The  pointer  P is  used  to  examine  the 
elements  of  the  PCI  sequentially,  The  test  on  line  5 will  fail  the  first  time,  since  all 
'mark'  fields  are  presumed  false  initially.  Thus  P corresponds  to  an  eligible  handler, 
as  the  notation  on  line  8 suggests.  (We  assume  that  the  handler  is  initiated  at  this 
point  and  the  selection  policy  indicates  whether  more  handlers  are  required.  See 
line  33.)  We  must  now  eliminate  (i.e.  mark)  all  handlers  on  the  DCL  that  P masks, 
which  is  the  effect  ot  lines  9 to  13.  A little  thought  reveals  that  such  handlers  are 
completely  characterized  by  the  test  on  line  10  and  the  fact  that  they  appear 
"deeper"  in  the  PCI  than  P does.y  Having  eliminated  ail  such  masked  handlers,  we 
now  must  eliminate  the  single  handler  on  the  SCL  that  P masks.  I inos  1 4 to  18  do 
this. 

On  subsequent  iterations  of  tire  mam  PCI  loop  (beginning  on  line  3),  the  test 

Q 

Recall  that  tf>*»  DCl  in  fart  a o.  h • of  M i ■ * s v.  on  » pother". 
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search:  beg  1 n "search" 

P*-DCL.next;  R*-SCL.next; 
wh i I e P*ni I do 
Q*-P.  nex  t ; 
i f P . mark 

then  P . mark*- f a I se 
e I se 

el  i g i b I e ( P ) : 
while  Qxni I do 

i f Q.mi=P.mi  and  Q.fi=P.fi 
then  Q.  mark*- true  f I ; 

Q-Q. nex  t 
od; 

wh  i I e R*n  i I clo 
if  R . m i =P . m i 

then  R.mark«-true;  ex  I t I pop 
e I se  R*-R  .next 
f i od; 

R*-5CL  . nex  t 

f_i_; 

P*-Q 

od: 

wh i I e R*n i I do 
i f R. mark 

then  R.mark*  false 
else  el i g i b I e ( R ) 
f [; 

R*-R . nex  t 
od 

end  " sear ch" ; 

while  Q*n  i I clo  Q.  mar  k*-  f a I se ; Q-Q.next  od; 
while  Rxnil  clo  R.  mar  k*- f a I se;  R*R.next  od 
wher e : 

e I i g i b I e ( X ) = < i nvoke  X ' 5 I land  I er  > ; 

if  no  more  handlers  needed  then  leave  search  fi 
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on  line  5 may  be  satisfied.  If  so.  we  have  encountered  a andler  previously 

determined  to  be  masked.  In  such  a case  we  merely  reset  its  mark  field  to  be 
false  and  proceed  to  the  next  DCL  element.  Observe  that  when  execution  passes 
to  line  23.  all  elements  of  the  DCL  will  again  have  their  'mark'  fields  set  to  false  and 
Q will  have  the  value  'nil*. 

The  search  of  the  SCI  on  lines  23  to  29  is  straight-forward  All  marked 
elements  have  their  'mark'  fields  set  to  false,  and  all  unmarked  elements  are 
considered  eligible.  Note  that,  by  virtue  of  lines  14  to  18,  an  element  of  the  SCL 
can  be  eligible  (unmarked)  if  and  only  if  no  element  of  the  DCL  has  a matching  'mi' 
field.  This  is  precisely  the  definition  of  eligibility  for  module-body  level  handlers,  i.e. 
the  handlers  corresponding  to  elements  on  the  SCI  Observe  that  when  execution 
passes  to  line  30,  all  elements  of  the  SCI  will  have  their  'mark'  fields  set  to  false 
and  R will  have  the  va  ue  'nil' 

If  control  reaches  line  31  from  line  30,  lines  ‘1  arid  3.  have  no  effect,  since 
Q=R=nil.  These  loops  exist  only  to  "clean  up'  the  D<  l 1 ; S<  l if  the  selection 
policy  causes  premature  termination  of  the  eligibility  ■■  a-  ’ ■*  is  easily  verified 
that  if  premature  termination  occurs,  all  list  element  ■ ' • e 0<  DCL 

(SCL)  and  Q (R)  already  have  their  'mark'  fields  set  to  false  thus  when  control 
passes  from  line  32,  all  list  elements  have  been  unmarked 

We  close  this  chapter  by  briefly  assessing  the  cost  of  this  algorithm.  At  first 
glance,  it  seems  quite  expensive.  However,  we  should  observe  that  the  DCL  is 
likely  to  be  quite  short,  unless  there  is  a high  degree  of  simultaneous  access  by 
parallel  processes  to  the  same  data  structure.  With  a short  DCL,  the  dominant  cost 
of  the  algorithm  becomes  the  search  of  the  SCL  incurred  for  each  unmarked  element 
of  the  DCl  (lines  1 4 to  1 8).  A clever  encoding,  however,  can  eliminate  the  search 
entirely.  Recall  that  the  ’mi'  field  is  defined  above  as  a unique  identifier  for  the 
instance  of  the  module  containing  the  handler  described  by  the  list  element.  Since 
elements  of  the  SCI  are  in  one-to-one  correspondence  with  such  instances,  the  'mi' 
field  can  be  taken  as  Ihe  address  of  the  appropriate  element  on  the  SCL1  'hi s 
address  is  bound  at  module  instantiation  time.  Now  there  is  no  need  to  search  the 
SCL  for  the  desired  element,  and  we  can  replace  lines  14  to  18  by 


u 


I p if  flip  p.v|,c  ''ar  <.plprt,on  policy.  P g '.rg  !>• 


i,i.a’  op  1 -„ai,  cl  i-s  not  rpqu’-p  t’w  p-  !•  p '•‘•giS’e  handlers  <,et. 
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R •-  P . m i ; 

R.roark  «-  true 

Wo  now  need  to  examine  each  element  of  the  SCI.  only  once  to  determine  all  its 

° ''"hle  handlerS  " WG  col',dr,,t  expect  to  d°  m“ch  better.  In  pathological  cases  the 
processing  of  a DC.  of  length  V can  still  require  0(n?)  list  element  accesses  but 
generally  we  expect  V to  be  relatively  small,  particularly  compared  to  the  length  of 
the  SCL.  We  also  expect  masking  to  reduce  the  processing  time  substantially. 
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in  Hip  preceding  chapters  we  established  a set  o(  goals  for  an  exceptional 
M,  n handling  mechanism,  then  defined  a particular  mechanism  and  verified  fl  at 
,t  ,i  :■  ml  met  the  goals.  We  have  argued  that  in  meeting  thesi  noah  , ti  e 
me  hamsm  significantly  advances  the  state  ot  the  art  it.  exception  handling  Yet 
the  goals  are  rather  general  in  character,  and  we  might  find  it  satisfying  to  a- ^"ss 
the  mechanism  in  terms  of  other,  more  sprcific  criteria  In  a sense,  such  an 
"independent  assessment"  confirms  that  the  proposed  mechanism  represents  a 
useful  step  forward  This  chapter  concludes  the  thesis  by  providing  that 
assessment  and  identifying  some  avenues  for  future  investigation. 


9.7  Contribution  of  this  Work 

To  obtain  a different  perspective  on  the  proposed  exception  handling 
mechanism,  let  us  return  to  the  list  of  issues  presented  in  section  2 .1  By 

examining  the  behavior  of  our  mechanism  with  respect  to  the  questions  posed  hen 
and  recalling  the  observations  of  chapter  2,  we  will  see  clearly  the  contribution  o' 
our  mechanism.  The  sections  below  respond  directly  to  the  quo  tions  of  sec  ■ > •• 
2.1  . 

9.1.1  Specification 

Our  mechanism  provides  for  explicit  naming  of  exceptional  conditions  IlK:ir 
semantics  are  precisely  defined  by  predicates  that  tell  a handler  what  it  an 
expect  and  what  it  must  do.  These  specifications  appear  in  the  module  that 
defines  the  exceptional  condition  and  are  exported  to  those  modules  that  use  it 
The  generality  of  this  specification  technique  permits  the  application  of  the 
mechanism  to  a wide  range  of  situations,  including  some  that,  under  traditionn 
definitions,  do  not  involve  exception  handling.  Our  mechanism  derives  muc  h of  its 
attractiveness  and  power  born  this  broad  applicability,  and  contrasts  sharply  with 
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many  existing  mechanisms  th.it  are  closely  tied  to  particular  language  or  system 
constructs. 


9.1.2  Abstraction 

Our  mi.  1...1  . • . m . • r . , i y . ...  miih-.i  with  the  preservation  of  abstractions 

(recall  the  .i.v  u-  n <if  e • i mi  4 \ ).  Ry  defining  the  sc  mantics  of  on  exception  in 
terms  of  the  at  ti  . t entity  p;iu  id<  I by  a module,  the  specification  technique 
supports  t In.  sepurat  >f  abstract  and  concrete  objects  and  distinguishes 
function  from  imi  n m< nit .i t n n A i ommon  failinq  of  existing  mechanisms  is  them 
inanility  to  fun  e pr< >gr ammers  to  use  only  the  als'iact  properties  of  a module  and 
ignore  its  repre  .ent.itn  mi  This  w‘.ikm>:,s  compromises  the  integrity  of  modules  by 
subveifirui  the  princ>i  > ct  i s apsutation  Our  mechanism  aids  abstraction  by 
placing  the  definition  r ( ex'  t ■ * ■ * 1 ‘ par  with  the  clc*  t *nit  ion  of  functions,  making 

it  possible  for  the  user  of  the  ah  traction  to  igiioie  all  representational  issues.  Ry 
forcing  programmers  to  define  exceptions  in  abstract  terms,  our  mechanism  also 
encourages  robust  module  d<  sign,  since  the  same  precision  is  required  to  specify 
exceptional  and  normal  case  behavior. 


9.1.3  Sharing 

We  have  dwelt  at  some  length  (particularly  in  section  3.1.3)  on  the 
inadequacy  of  the  "calls"  hierarchy  for  exception  transmission.  It  is  remarkable 
that  the  central  notion  of  shared  abstractions  has  been  almost  totally  ignored  by 
existing  exception  mechanisms.  Indeed,  one  of  the  most  significant  properties  of 
our  proposed  mechanism  is  its  ability  to  support  shared  abstractions  in  a natural 
way.  Once  wo  realize  that  sharing  is  of  crucial  importance,  we  see  that  particular 
kinds  of  sharing,  e g.  asynchronous,  parallel  access,  can  tie  accommodated  as 
important  subcases.  Thus  we  gain  the  ability  to  handle  exceptions  in  both 
sequential  and  parallel  programming  environments  without  introducing  special 
facilities  for  either  one.  Ry  recognizing  sharing  as  the  fundamental  property, 
parallel  sharing  "falls  out"  as  a special  case.  We  also  elevate  a concept  long 
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recognized  as  Important  In  operating  systems  to  the  level  it  deserves  in 
programming  languages. 


9.1.4  Programming  Flexibility 

There  is  no  question  that  our  specification  technique  forces  the  programmer  to 
consider  the  "exceptional  case"  behavior  of  his  program  much  more  carefully  It  he 
wishes  to  produce  a robust  program,  the  mechanism  can  aid  him  in  expressing 
exception  processing  requirements.  However,  it  may  also  constrain  the  modes  of 
expression  he  can  use  for  related,  but  non-exceptiona1  case  processing.  We 
believe  that  such  restrictions,  rather  than  limiting  flexibility,  enhance  clarity  and 
contribute  to  correctness,  just  as  disciplined  transfers  of  control  ami  data 
structuring  techniques  do  It  is  true  that  our  mechanism  does  not  mesh  well  witn 
some  familiar  programming  constructs  (such  as  the  non-local  goto),  and  we  have  no 
qualms  about  imposing  restrictions  on  such  constructs  when  they  affect  program 
clarity  and  coherent  exception  processing.  The  examples  of  chapter  7 illustrate 
that  a considerable  variety  of  applications  can  still  be  programmed  in  a natural  way 
while  utilizing  the  facilities  of  our  exception  mechanism. 


9.1.5  Language 

In  section  5.1  we  examined  the  relationship  between  our  exception 
mechanism  and  its  embedding  language.  Ideally,  of  course,  the  addition  of  an 
exception  handling  facility  should  not  perturb  the  language  at  all.  Our  mechanism  is 
largely  language-independent  and  imposes  very  lew  restrictions  on  its  embedding 
language.  No  specific  properties,  other  than  the  ability  to  support  abstraction  by 
encapsulation,  are  required.  While  several  language  features,  e.g.  scope  rules, 
naturally  interact  with  the  exception  handling  mechanism,  none  is  constrained  to 
assume  a particular  form  (in  contrast  to  many  existing  mechanisms)  The  most 
significant  effect  on  the  language  induced  by  the  exception  mechanism  appears  in 
the  synchronization  facilities  (if  any).  Here,  the  requirements  of  the  mechanism, 
while  defined  separately  from  the  language  facility,  interact  with  It  in  non  obvious 
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ways.  Section  5.2  shows  how  the  complexities  of  this  interaction  may  be  reduced 
and  the  combination  of  the  two  mechanisms  used  to  the  programmer's  advantage. 


9.1.6  Vet If ication 

Chapter  6 demonstrates  the  verifiability  of  the  proposed  mechanism  within  the 
context  of  a particular  modern  programming  language.  We  were  careful  to  define 
the  semantics  of  the  exception  mechanism  to  limit  its  effect  on  the  verifiability  of 
the  host  language  Specifically,  its  semantics  were  tailored  to  fit  existing  program 
structures,  particularly  abstract  functions.  Although  the  desire  for  verifiability  has 
affected  the  fine  points  of  the  mechanism,  the  power  of  the  facility  has  not  been 
compromised  by  that  desire.  The  examples  of  chapter  7.  complete  with  pre-  and 
post-conditions,  support  that  conclusion.  While  the  details  of  verification  will 
necessarily  vary  from  language  to  language,  the  semantic  specification  is  relatively 
general  and  should  adapt  easily  to  most  inductive  assertion-based  proof 
methodologies. 


9.1.7  Cost 

The  algorithms  presented  in  chapter  8 show  that  a cost-effective 
implementation  of  the  proposed  mechanism  doers  exist  f urther,  the  costs  are 

distributed  to  minimize  overhead  in  the  non-exc.eptional  case  We  have  also  seen 
that  if  the  mechanism  is  to  be  used  more  for  communication  than  exception 
processing,  the  costs  can  he  balanced  somewhat  more  equitably  between  the 
maintenance  of  the  eligible  handlers  set  and  the  actual  transmission  of  an 
exceptional  condition.  It  is  difficult  to  assess  the  cost-effectiveness  of  this 
mechanism  with  respect  to  potentially  attractive  alternative’s,  since  the  latter  are 
clearly  language-specific.  In  Alphard  there  are  no  obvious  contenders.  In 
languages  that  support  procedure  variables,  it  is  evident  (see  section  2.2.d)  that 
for  approximately  equal  overhead  cost  we  get  considerably  creator  flexibility  from 
our  proposed  mechanism.  Most  of  the  other  mechanisms  of  chapter  2 do  not  provide 
sufficient  function  to  be  considered  "attractive  alternatives"  to  our  proposal. 
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9.2  Remaining  Issues 

At  a number  of  points  in  the  preceding  chapters,  we  have  identif  id  issues 
tlret  merit  further  investigation.  In  this  final  section  we  briefly  recapitulate  these 
issues  and  append  a few  others  that  logically  follow  from  this  work.  We  believe 
that  the  successful  resolution  of  each  of  these  questions  will  ■nn.ic  e the 
mechanism's  applicability  and  hence  its  value  as  a program  stria  luring  tool. 

9.2.1  Solection  Policy  Primitives 

In  section  d.r.l  we  established  principles  that  selection  pun  tos  should 
exhibit  and  gave  three  specific  illustrations.  We  can  ask  whether  a language 
should,  in  lieu  of  particular  policies,  supply  primitives  tl  at  permit  if  rcjran  n to 
define  their  own.  Such  primitives  would  necessarily  be  engineered  only  to  produce 
policies  that  satisfy  the  postulated  properties.  By  developing  sut  h primitives  wo 
can  gain  insight  into  the  range  of  interar  tions  between  si  jnalU  r and  t v dter  >nd 
we  may  identify  additional  or  alternate  properties  that  more  precisely  bound  the 
space  of  ttiose  interactions 


9.2.2  Verification  of  Synchronization 

In  chapter  G we  ignored  the  difficulties  in  verification  < auseil  try  the 
existence  of  parallelism  within  programs  that  may  use  the  rxi  option  mechanism. 
Tlie  field  of  verification  of  parallel  programs  is  one  of  considerable  re  ent  research 
interest,  and  positive  results  in  this  area  would  enable  us  to  complete  the  formal 
specification  of  our  mechanism's  semantics.  In  particular,  the  synchtoni.  ation 
requirements  of  sele<  tion  policies  could  then  he  precisely  exprosseri,  po’haps 
assisting  tn  the  development  of  additional  ehnrncteristif  pro|>erties  (see  above) 
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9.2.3  Usage  Paradigms 

Section  5.2  discusses  the  problem  of  combining  language  primitives  in 
coherent  ways.  Although  the  principle  of  "orthogonal  design"  espoused  by  Alqol-63 
[van  Wijngaarden  75]  is  a laudable  one,  in  practice  few  languages  achieve 
complete  orthogonality.  The  subtle  (and  sometimes  undesirable)  interactions  of  our 
exception  mechanism  with  synchronization  primitives  (see  section  5.  I d)  is  an 
example.  The  difficulties  can  be  eliminated,  in  large  part,  by  supplying  a sufficiently 
rich  collection  of  "composite  operations",  which  respond  to  commonly  occurring 
programming  situations  Section  5.2  illustrates  a few  such  "usage  paradigms",  but 
doubtless  many  others  can  be  found.  By  accumulating  a collection  of  useful 
"higher-level"  operations,  we  encourage  the  use  of  the  exception  mechanism,  since 
the  composite  actions  are,  in  effect,  "pre-tested"  applications  of  the  mechanism. 


9.2.4  Protection 

If  we  consider  our  mechanism  in  a system  rather  than  a language  context,  we 
become  aware  of  a number  of  protection  issues.  In  section  5.1.5  we  briefly 
mentioned  the  possibility  that  our  mechanism  contains  covert  channels  for  leaking 
information  from  a confined  domain.  There  are  other  questions  as  well,  e g.  should 
restricting  the  rights  in  a capability  also  restrict  the  exceptions  that  may  be 
handled  by  the  environment  possessing  that  capability?  1 he  solutions  to  these 
questions  will  enhance  the  application  of  the  exception  mechanism  to  systems  in 
which  protection  is  a serious  concern. 


9.2.5  Enforcement 

A related  issue  is  enforcement  We  rely  heavily  on  a compiler/verifier  to 
ensure  that  modules  meet  certain  of  their  specifications.  Many  operating  systems 
take  a more  conservative  approach  and  enforce  specifications  at  run-time.  In  this 
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way  they  ensure  that  no  hicjher-level  (in  the  sense  ot  the  "uses"  relation)  error, 
inadvertent  or  deliberate,  can  result  in  a violation  of  specifications.  Of  course, 
there  is  a certain  cost  incurred  by  doing  all  checks  dynamically,  and  for  some  of  the 
features  of  the  exception  mechanism  (e.g  ensuring  that  a handler  cannot  cause  its 
associated  condition  to  be  signalled  anew),  that  cost  may  Ire  substantial  It  is  an 
open  question  whether  our  exception  mechanism  can  be  implemented  with 
reasonable  efficiency  in  a system  that  enforces  all  specifications  at  run-time 


9.2.6  Hardware  Applicability 

There  are  at  least  two  important  open  questions  concerning  the  interaction  of 
our  mechanism  and  hardware  design  I irst,  how  can  microcode  be  used  to  reduce 
the  implementation  costs  of  the  mechanism?  Is  it  feasible,  for  example  to  move  the 
eligible  handler  set  maintenance  into  firmware?  Second,  what  is  the  effect  of  the 
exception  mechanism  on  system  architecture?  Do  we  have  to  revise  our  view  of 
processor-channel-device  communication?  Is  the  mechanism  sufficiently  general  to 
accommodate  sharing  at  the  instruction  or  memory  cycle  level?  Because  the  ratio 
of  hardware  to  software  cost  is  small  in  many  modern  systems,  we  may  need  to  re- 
evaluate the  communication  schemes  we  have  used  to  date  and  incorporate  new 
ones  that  are  more  in  line  with  the  proposed  mechanism.  If  the  goal  of  uniformity  is 
to  he  completely  achieved,  we  must  explore  the  possibility  of  making 
bardware/sof t ware  and  software/software  interfaces  consistent. 


9.2.7  Uniform  Control  Structure 

there  is  a constant  tension  between  the  desires  for  pleasing  conceptual 
uniformity  and  special  case  efficiency.  At  several  places  we  have  remarked  that 
our  proposal  can  serve  as  a communication  tool,  yet  we  persist  in  calling  it  an 
exception  handling  mechanism.  Is  there  a more  general  view  of  control  flow 
structure  that  brings  exceptional  and  normal  case  together  in  a single,  consistent 
fashion?  Of  course  - production  systems  are  an  example  Vet  we  the  programming 
public  have  not  abandoned  our  conventional  Algol-like  languages  In  favor  ot  this 
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more  unified  view.  This  Is  due  in  part  to  the  (potential)  loss  of  efficiency  in  special 
cases  - efficiency  we  deeply  cherish.  Wo  stick  to  programming  with  a set  of 
constructs  each  tailored  to  a particular  task  precisely  because  we  are  unwilling  to 
ignore  efficiency  to  gain  uniformity.  If  a way  were  known  to  eliminate  the  tension 
between  these  two  fundamental  concerns,  this  thesis  would  never  have  been 
written.  As  it  is,  we  know  of  no  way  to  "have  our  cake  and  eat  it  too",  so  we 
continue  to  look  for  language  primitives  that  supply  special  case  semantics  at  low 
cost.  There  is  an  obvious  avenue  of  investigation  open  here;  no  doubt  many 
language  designers  believe  they  are  walking  down  it  Clearly,  a complete  solution 
to  this  problem  would  make  the  mechanism  we  propose  obsolete. 

9.2.8  Self  Applicability 

l et  us  close  by  looking  inward  instead  of  outward.  The  proposed  mechanism 
implements  an  abstraction  of  its  own,  just  as  the  language  in  which  it  is  embedded 
does.  Exceptions  in  the  language  abstractions  may  be  expressed  using  the 
exception  mechanism  (e  g.  inability  to  perform  some  language-supplied  primitive 
because  of  a catastrophic  error  of  some  obscure  sort).  Can  failures  of  the 
exception  mechanism  be  so  expressed?  Can  we  apply  the  concepts  of  exception 
handling  explored  in  this  thesis  to  the  mechanism  itself?  Obviously,  the  mechanism 
should  be  robust,  and  it  can  employ  various  redundancy  techniques  to  check  its  own 
operation,  yet  there  is  bound  to  come  a point  at  which  the  mechanism  is  forced  to 
admit  failure  to  its  users.  This  circularity  leads  us  to  the  so-called  "hard-core 
reliability  problem",  that  is,  the  need  to  assume  that  there  is  a "hard-core"  nucleus 
of  software  whose  operation  we  trust  implicitly.  System  designers  abhor  such 
"hard-cores",  because  they  represent  singularities  in  the  system  (and  because 
they  too  often  prove  to  be  "soft-cores"!)  Must  we  resign  ourselves  to  trusting  the 
(implementation  of  the)  exception  handling  mechanism,  or  can  we  discover  ways  to 
make  the  mechanism  self-applicable?  The  impact  of  a solution  to  this  admittedly 
difficult  problem  would  extend  beyond  the  exception  mechanism  and  cause  us  to 
revise  our  present  approach  to  reliable  system  design. 
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Appendix  A 

A More  Flexible  Handler  Definition 

"It's  far  too  clear,"  he  said.  "It  should  be  writ  in 
such  a way  that  it  you  ever  changed  your  mind, 
the  point  could  he  disowned,  denied,  and 
d i savowed 

- James  Thurber,  The  White  Deer 

In  section  4.9  we  defined  a syntax  that  permits  a handler  to  effect  a local 
transfer  of  control.  There  are  programming  situations  in  which  the  unconditional 
posting  of  a transfer  of  control  (in  the  terminology  of  that  section)  is  inconvenient: 
a more  flexible  dynamic  determination  may  be  preferable.  Tor  example,  a handler 
might  wish  to  retry  a failing  operation  three  times  before  ultimately  giving  up 
Obviously,  the  actions  'retry'  and  'give-up'  correspond  to  different  control  points  in 
the  associated  context.  The  syntax  of  section  4.9  makes  such  a handler  rather 
awkward  to  write  In  this  appendix  we  suggest  a change  to  the  exception 
mechanism  of  chapter  4 that  permits  such  a handler  to  be  specified  without 
compromising  verifiability. 

A more  general  form  of  handler  specification  would  permit  a completely 
dynamic  determination  of  the  point  in  the  associated  context  at  which  execution 
will  resume.  First,  we  relax  the  requirement  that  the  handler  body  be  a single 
procedure  invocation,  permitting  instead  an  arbitrary  block.  Second,  we  introduce  a 
language  construct  'post  I',  where  'I'  is  a label  This  construct  may  appear  only 
within  a handler  and  'I'  must  reference  a label  within  the  enclosing  function  body. 
When  'post  I'  is  executed,  T is  frosted  as  the  location  to  which  control  is  to  be 
transferred  when  execution  resumes  in  the  associated  context H I xecution  of  the 
handler  is  then  terminated/’ 


^ Some  implementations  may  wish  1r>  restrict  to  be  a label  constant,  not  a variable 
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It  should  be  evident  that  'post  I'  has  the  effect  of  (dynamically)  inserting  a 
'goto  I'  at  the  point  of  interruption  of  the  associated  context.  The  usual  proof  rule 
for  'goto  I'  [Clint  72]  requires  an  assertion  to  be  supplied  at  T,  and  we  make  a 
similar  requirement  for  'post  I1.  It  Is  then  a simple  matter  to  extend  the  handler 
proof  rule  in  section  6.5  to  include  the  proof  rule  for  the  goto.  We  omit  the  details 
here,  noting  only  that  while  the  extension  is  conceptually  straightforward,  it  may 
induce  considerable  (albeit  mechanical)  effort  in  the  verification  process. 
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The  Alphard  Verification  Methodology 

[Note  This  appendix  is  taken  from  [t.ondon  76]  with  slight  modifications  ] 

Alphard's  verification  methodology  is  designed  to  determine  whether  a form 
will  actually  behave  os  promised  by  its  abstract  specifications  The  rm  thodology 
depends  on  explicitly  separating  the  description  of  how  an  object  behaves  from  the 
code  that  manipulates  the  representation  in  order  to  achieve  that  behavior.  It  ts 
derived  trom  Hoare's  to  Ivngue  for  showing  corrector’  s of  data  representations 
[Hoare  7?] 

The  abstract  object  and  its  behavior  are  described  in  terms  of  some 
mathematical  entdn-  i • n , f tin  piohlem  domain  (eg  graphs  sequences).  We 
appeal  to  these  abstract  t/pes 

in  the  invariant  which  explains  that  an  instantiation  of  the  form 
may  be  vowed  is  an  objoct  of  the  abstract  type  that  meets 
certain  restrictions, 

in  the  initially  clause,  whore  a particular  abstract  object  is 
displayed,  and 

in  the  pro  and  post  conditions  for  each  function,  which  describe 
the  effect  the  function  has  on  an  abstract  object  that  satisfies 
the  invariant. 


The  form  contains  a parallel  set  of  descriptions  of  the  concrete  object  and 
how  it  behaves.  In  many  cases  this  makes  the  effect  of  a function  much  easier  Vo 
sprc.ify  and  verify  than  would  the  abstract  descrijition  alone. 

Now,  although  it  is  useful  to  distinguish  between  the  behavior  we  want  and 
the  data  structures  we  operate  on,  we  also  need  to  show  a relationship  that  holds 
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between  the  two.  This  is  achieved  with  ttie  representation  function  rep(x),  which 
cjives  a mapping  from  the  concrete  representation  to  the  abstract  cfescription.  The 
purpose  of  a form  verification  is  to  ensure  that  the  two  invariants  and  the  rep(x) 
relation  between  them  are  preserver! 

In  order  to  verify  a form  we  must  therefore  prove  four  things.  Two  relate  to 
the  representation  itself  and  two  must  be  shown  for  each  function.  Informally,  the 
four  required  steps  are  ' 

For  the  form 

1.  Representation  validity 

lc(x)  |g(rep(x)) 

2.  Initialization 

requires  { init  clause  } initially  (rep(x))  A l^.tx) 

For  each  function 

o.  Concrete  operation 

in(x)  A l(  ( x ) { function  body  } out( x ) A |(,  (x ) 

d.  Relation  between  abstract  and  concrete 

da.  Ic(x)  A pre(repfx))  in(x) 

db.  Ic(x)  A pre(rep(x'))  A out(x)  o post(rep(x)) 

Step  1 shows  that  any  legal  state  of  the  concrete  representation  has  a 
c.orr ospoiuling  abstract  object  (the  converse  is  deducible  from  the  other  steps). 
Step  2 shows  that  the  initial  state  created  by  the  representation  section  is  legal. 
Step  3 is  the  standard  verification  formula  for  the  concrete  operation  as  a simple 


We  Will  use  Mrpp(v})  1 r delete  |',«  ,-«l  < ■ a I « .v  i i a-*  - bje  I whose  connele  r epi esentation  is  x,  l^(x) 
to  denote  the  c ■ ir r • j • ' g • >'le  « .v  .«■  • it«l  s t-  feter  ' rode  segments,  and  the  names  of  specif icahon 
clauses  and  a'  < • t ' * !■  'eter  i th  * ‘ as  ^iep  1b  * rep(x'))"  lelets  to  the  value  of  x hefote 
r*rrul»on  of  U « fr-  • 1 A . ^ ,«,»•*»♦  »■  f*ra1«on  m^thodf'l  gy'  appears  in  [Wulf  7C>«1, 

Wulf  76b] 
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program;  note  that  it  enforces  the  preservation  of  lc.  Step  4 guarantees  (a)  that 
the  concrete  operation  is  applicable  whenever  the  abstract  pre  condition  holds  and 
(b)  that  if  the  operation  is  performed,  the  result  corresponds  properly  to  the 
abstract  specifications. 
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